<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">

    <title>DIF Sidetree Protocol</title>
    <link href="https://identity.foundation/sidetree/spec-up/css/custom-elements.css" rel="stylesheet">
    <link href="https://identity.foundation/sidetree/spec-up/css/prism.css" rel="stylesheet">
    <link href="https://identity.foundation/sidetree/spec-up/css/chart.css" rel="stylesheet">
    <link href="https://identity.foundation/sidetree/spec-up/css/font-awesome.css" rel="stylesheet">
    <link href="https://identity.foundation/sidetree/spec-up/css/index.css" rel="stylesheet">
    <script src="https://identity.foundation/sidetree/spec-up/js/custom-elements.js"></script>
</head>

<body features="source logo">

    <svg id="svg" version="1.1" xmlns="http://www.w3.org/2000/svg">
        <symbol id="github" viewBox="0 0 20 20">
            <path
                d="M10 0.247c-5.522 0-10 4.477-10 10 0 4.418 2.865 8.167 6.839 9.489 0.5 0.093 0.683-0.217 0.683-0.481 0-0.238-0.009-1.026-0.014-1.862-2.782 0.605-3.369-1.18-3.369-1.18-0.455-1.156-1.11-1.463-1.11-1.463-0.907-0.621 0.069-0.608 0.069-0.608 1.004 0.071 1.533 1.031 1.533 1.031 0.892 1.529 2.339 1.087 2.91 0.831 0.090-0.646 0.349-1.087 0.635-1.337-2.221-0.253-4.556-1.11-4.556-4.942 0-1.092 0.391-1.984 1.030-2.684-0.104-0.252-0.446-1.269 0.097-2.646 0 0 0.84-0.269 2.751 1.025 0.798-0.222 1.653-0.333 2.503-0.337 0.85 0.004 1.706 0.115 2.505 0.337 1.909-1.294 2.747-1.025 2.747-1.025 0.544 1.378 0.202 2.395 0.098 2.646 0.641 0.7 1.029 1.592 1.029 2.684 0 3.841-2.339 4.687-4.566 4.934 0.359 0.31 0.678 0.919 0.678 1.852 0 1.338-0.012 2.415-0.012 2.744 0 0.266 0.18 0.578 0.687 0.48 3.971-1.324 6.833-5.071 6.833-9.488 0-5.523-4.477-10-10-10z">
            </path>
        </symbol>
        <symbol id="nested_list" viewBox="0 0 37 32">
            <path
                d="M0 2.286c0-1.262 1.023-2.286 2.286-2.286s2.286 1.023 2.286 2.286c0 1.262-1.023 2.286-2.286 2.286s-2.286-1.023-2.286-2.286zM9.143 0h27.429v4.571h-27.429zM9.143 11.429c0-1.262 1.023-2.286 2.286-2.286s2.286 1.023 2.286 2.286c0 1.262-1.023 2.286-2.286 2.286s-2.286-1.023-2.286-2.286zM18.286 9.143h18.286v4.571h-18.286zM9.143 29.714c0-1.262 1.023-2.286 2.286-2.286s2.286 1.023 2.286 2.286c0 1.262-1.023 2.286-2.286 2.286s-2.286-1.023-2.286-2.286zM18.286 27.429h18.286v4.571h-18.286zM18.286 20.571c0-1.262 1.023-2.286 2.286-2.286s2.286 1.023 2.286 2.286c0 1.262-1.023 2.286-2.286 2.286s-2.286-1.023-2.286-2.286zM27.429 18.286h9.143v4.571h-9.143z">
            </path>
        </symbol>
    </svg>

    <main>

        <header id="header" class="panel-header">
            <span id="toc_toggle" panel-toggle="toc">
                <svg icon>
                    <use xlink:href="#nested_list"></use>
                </svg>
            </span>
            <a id="logo" href="https://identity.foundation">
                <img
                    src="https://rawcdn.githack.com/decentralized-identity/decentralized-identity.github.io/a3ca39717e440302d1fd99a796e7f00e1c42eb2d/images/logo-flat.svg" />
            </a>
            <span issue-count animate panel-toggle="repo_issues">
                <svg icon>
                    <use xlink:href="#github"></use>
                </svg>
            </span>
        </header>

        <article id="content">
            <h1 id="sidetree"><a class="toc-anchor" href="#sidetree">§</a> Sidetree</h1>
            <p><strong>Specification Status:</strong> Editor’s Draft v0.1.0</p>
            <p><strong>Latest published version:</strong>
                <a href="https://identity.foundation/sidetree/spec">identity.foundation/sidetree/spec</a></p>
            <dl>
                <dt><strong>Editors:</strong></dt>
                <dd><a href="https://www.linkedin.com/in/dbuchner/">Daniel Buchner</a> (Microsoft)</dd>
                <dd><a href="https://www.linkedin.com/in/or13b/">Orie Steele</a> (Transmute)</dd>
                <dt><strong>Contributors:</strong></dt>
                <dd><a href="https://www.linkedin.com/in/henry-tsai-6b884014/">Henry Tsai</a> (Microsoft)</dd>
                <dd><a href="https://www.linkedin.com/in/troyronda/">Troy Ronda</a> (SecureKey)</dd>
                <dd><a href="https://www.linkedin.com/in/mudassir-ali-4981654/">Mudassir Ali</a> (Microsoft)</dd>
                <dd><a href="https://www.linkedin.com/in/guillaume-dardelet/">Guillaume Dardelet</a> (Transmute)</dd>
                <dd><a href="https://www.linkedin.com/in/isaac-chen-921079127/">Isaac Chen</a> (Microsoft)</dd>
                <dd><a href="https://www.linkedin.com/in/chrislun/">Christian Lundkvist</a> (Consensys)</dd>
                <dd><a href="https://www.linkedin.com/in/kyledenhartog/">Kyle Den Hartog</a> (Mattr)</dd>
                <dt><strong>Participate:</strong></dt>
                <dd><a href="https://github.com/decentralized-identity/sidetree">GitHub repo</a></dd>
                <dd><a href="https://github.com/decentralized-identity/sidetree/issues">File a bug</a></dd>
                <dd><a href="https://github.com/decentralized-identity/sidetree/commits/master">Commit history</a></dd>
            </dl>
            <p><strong>Sidetree REST API specification:</strong>
                <a href="https://identity.foundation/sidetree/api">identity.foundation/sidetree/api</a></p>
            <hr>
            <h2 id="abstract"><a class="toc-anchor" href="#abstract">§</a> Abstract</h2>
            <p>Sidetree is a protocol for creating scalable decentralized public key infrastructure (DPKI) networks that
                can run atop of any existing decentralized ledger system (e.g. Bitcoin) and be as open, public, and
                permissionless as the underlying ledger they utilize. The protocol allows users to create globally
                unique, user-controlled identifiers and manage their associated metadata, all without the need for
                centralized authorities or trusted third parties. The syntax of the identifier and accompanying data
                model used by the protocol is conformant to that defined by <a
                    href="https://w3c.github.io/did-core/">W3C Decentralized Identifiers</a>. Implementations of the
                protocol can be codified as their own distinct <em>DID Methods</em> and registered in the <a
                    href="https://w3c-ccg.github.io/did-method-registry/">W3C DID Method Registry</a>.</p>
            <h2 id="introduction"><a class="toc-anchor" href="#introduction">§</a> Introduction</h2>
            <p><em>This section is non-normative</em></p>
            <p>Decentralized ledgers (e.g. Bitcoin) introduced the first-ever solution to the linear chronological
                oracle problem, which unlocked the ability to create robust decentralized identifier networks. However,
                current approaches that utilize these ledger systems to create decentralized identifier networks suffer
                from severely limited transactional volumes and other performance issues. Sidetree is a ‘Layer 2’
                protocol that runs atop decentralized ledger systems to enable scalable <a
                    href="https://w3c.github.io/did-core/">W3C <em>Decentralized Identifier</em></a> (DID)
                implementations that can be fully open, public, and permissionless. Sidetree is able to do all this
                without requiring trusted intermediaries, centralized authorities, special protocol tokens, or secondary
                consensus mechanisms, while preserving the core attributes of decentralization and immutability of the
                underlying ledger systems it is implemented on.</p>
            <p>Architecturally, Sidetree-based DID Method implementations are overlay networks composed of independent
                peer nodes (<em>Sidetree nodes</em>) that observe an underlying decentralized ledger (as illustrated
                under <a href="#network-topology">Network Topology</a>), replicate ledger-anchored DID PKI state
                operations, and execute against that data a set of deterministic protocol rules to produce an eventually
                strongly consistent view of all DIDs in the network. The Sidetree protocol defines a core set of DID PKI
                state change <em>operations</em>, structured as delta-based Conflict-Free Replicated Data Types (i.e. <a
                    href="#create">Create</a>, <a href="#update">Update</a>, <a href="#recover">Recover</a>, or <a
                    href="#deactivate">Deactivate</a>), that mutate a Decentralized Identifier’s <em>DID Document</em>
                state. <em>Sidetree nodes</em> that participate in writing operations into the overlay network do so by
                anchoring <em>Content-Addressable Storage (CAS)</em> (e.g. IPFS) references to aggregated bundles of
                <em>operations</em> in an underlying ledger. The ledger acts as a linear chronological sequencing
                oracle, which the protocol leverages to order DID PKI operations in an immutable history all observing
                nodes can replay and validate. It is this ability to replay the precise sequence of DID PKI state change
                events, and process those events using a common set of deterministic rules, that allows <em>Sidetree
                    nodes</em> to achieve a consistent view of DIDs and their <em>DID Document</em> states, without
                requiring any additional consensus mechanism.</p>
            <h2 id="terminology"><a class="toc-anchor" href="#terminology">§</a> Terminology</h2>
            <table>
                <thead>
                    <tr>
                        <th>Term</th>
                        <th>Description</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td id="ledger">Ledger</td>
                        <td>A decentralized linear sequencing oracle (e.g. Bitcoin) that can be used to anchor the PKI
                            state transformations of Decentralized Identifiers (DIDs) in a shared record that can be
                            deterministically replayed by observers to derive the current PKI state of DIDs.</td>
                    </tr>
                    <tr>
                        <td>Anchor File</td>
                        <td>JSON Document containing proving and index data for Create, Recovery, and Deactivate
                            operations, and a CAS URI for the associated Map File. This file is anchored to the target
                            ledger.</td>
                    </tr>
                    <tr>
                        <td>Map File</td>
                        <td>JSON Document containing Update operation proving and index data, as well as CAS URI for
                            Chunk File chunks.</td>
                    </tr>
                    <tr>
                        <td>Chunk File</td>
                        <td>JSON Document containing all verbose operation data for the corresponding set of DIDs
                            specified in the related Map File.</td>
                    </tr>
                    <tr>
                        <td id="cas">CAS</td>
                        <td>Content-addressable storage protocol/network (e.g. IPFS)</td>
                    </tr>
                    <tr>
                        <td id="cas-uri">CAS URI</td>
                        <td>The unique content-bound identifier used to locate a resource via the <a href="#cas">CAS</a>
                            protocol/network (e.g. IPFS)</td>
                    </tr>
                    <tr>
                        <td id="commit-value">Commit Value</td>
                        <td>A chosen value that is used with a <a href="#commitment-scheme">commitment scheme</a></td>
                    </tr>
                    <tr>
                        <td id="commitment">Commitment</td>
                        <td>The output of a <a href="#commitment-scheme">commitment scheme</a></td>
                    </tr>
                    <tr>
                        <td id="commitment-scheme">Commitment Scheme</td>
                        <td>A cryptographic primative that allows one to commit to a chosen value, known as the <a
                                href="#commit-value">commit value</a> resulting in the generation of a <a
                                href="#commitment">commitment</a>. A <a href="#commitment">commitment</a> can then be
                            shared without revealing the <a href="#commit-value">commit value</a> forming a
                            <code>proof of commitment</code> where the possessor of the <a href="#commit-value">commit
                                value</a> can then later reveal the <a href="#commit-value">commit value</a> proving the
                            original commitment.</td>
                    </tr>
                    <tr>
                        <td>DID Document</td>
                        <td>JSON Document containing public key references, service endpoints, and other PKI metadata
                            that corresponds to a given DID (as defined in the <a
                                href="https://w3c.github.io/did-core/">W3C DID Specification</a>).</td>
                    </tr>
                    <tr>
                        <td id="did-suffix">DID Suffix</td>
                        <td>The unique identifier string within a DID URI. e.g. The unique suffix of
                            <code>did:sidetree:123</code> would be <code>123</code>.</td>
                    </tr>
                    <tr>
                        <td>DID Suffix Data</td>
                        <td>Data required to deterministically generate a DID.</td>
                    </tr>
                    <tr>
                        <td id="multihash">Multihash </td>
                        <td>Protocol for differentiating outputs from common cryptographic hash functions, addressing
                            size + encoding considerations: <a
                                href="https://multiformats.io/multihash/">https://multiformats.io/multihash/</a></td>
                    </tr>
                    <tr>
                        <td>DID Operation</td>
                        <td>Set of delta-based modifications that change the state of a DID Document when applied.</td>
                    </tr>
                    <tr>
                        <td>Operation Request</td>
                        <td>JWS formatted request sent to a <em>Sidetree Node</em> to include a <em>DID Operation</em>
                            in a batch of operations.</td>
                    </tr>
                    <tr>
                        <td id="operation-key-pair">Operation Key Pair</td>
                        <td>A cryptographic key used to produce an <em>Operation Request</em> JWS. Public key
                            representation MAY be present in the DID Document. Public key representation MUST be used to
                            produce <em>Operation Request</em> commitment.</td>
                    </tr>
                    <tr>
                        <td id="recovery-key-pair">Recovery Key Pair</td>
                        <td>A cryptographic key used to produce an <em>Operation Request</em> of type Recover or
                            Deactivate. Public key representation MAY be present in the DID Document. Public key
                            representation MUST be used to produce <em>Operation Request</em> commitment.</td>
                    </tr>
                    <tr>
                        <td id="public-key-commitment">Public Key Commitment</td>
                        <td>The resulting <a href="#commitment">commitment</a> obtained by applying the defined <a
                                href="#operation-commitment-scheme">commitment scheme</a> to a public key</td>
                    </tr>
                    <tr>
                        <td id="recovery-commitment">Recovery Commitment</td>
                        <td>The resulting <a href="#commitment">commitment</a> obtained by applying the defined <a
                                href="#recovery-commitment-scheme">commitment scheme</a> to the public key of a <a
                                href="#recovery-key-pair">recovery key pair</a></td>
                    </tr>
                    <tr>
                        <td>Sidetree Node</td>
                        <td>Executable code that implements all the required components, functionality, and rules
                            specified in the Sidetree protocol specification.</td>
                    </tr>
                    <tr>
                        <td>Transaction</td>
                        <td>Ledger transaction that anchors a set of Sidetree operations, via a CAS URI for an
                            associated Anchor File.</td>
                    </tr>
                    <tr>
                        <td>Anchor String</td>
                        <td>The string anchored to the ledger, composed of the CAS URI to the <a
                                href="#anchor-file">Anchor File</a>, prefixed with the declared operation count .</td>
                    </tr>
                    <tr>
                        <td id="ledger-time">Ledger Time</td>
                        <td>The deterministic logical clock variable manifested in the underlying ledger system that can
                            be used as a deterministic chronological reference (e.g. Bitcoin block numbers).</td>
                    </tr>
                    <tr>
                        <td id="transaction-number">Transaction Number </td>
                        <td>A monotonically increasing number deterministically ordered and assigned to every
                            transaction relative to its position in <a href="#ledger-time">Ledger Time</a>.</td>
                    </tr>
                    <tr>
                        <td id="light-node">Light Node </td>
                        <td>A node that downloads and processes only <a href="#anchor-file">Anchor Files</a> and <a
                                href="#map-file">Map Files</a> on a proactive basis, waiting until resolution time to
                            download and process the <a href="#chunk-files">Chunk File</a> related to a given DID. This
                            type of configuration enables a node to operate trustlessly while consuming approximately
                            one order of magnitude less storage.</td>
                    </tr>
                </tbody>
            </table>
            <h2 id="protocol-versioning"><a class="toc-anchor" href="#protocol-versioning">§</a> Protocol Versioning
            </h2>
            <p>The rules and parameters of the Sidetree protocol MAY change in the future, resulting in new versions of
                the specification. The Sidetree specification and reference implementation follow <a
                    href="https://semver.org/">SemVer 2.0</a>.</p>
            <p>Versions of the specification can be found on the Decentralized Identity Foundation’s website at the
                following version-based paths:</p>
            <p><strong>Latest Draft</strong></p>
            <pre class="language-html"><code class="language-html">https://identity.foundation/sidetree/spec/
</code></pre>
            <p><strong>Specific Versions</strong></p>
            <pre class="language-html"><code class="language-html">https://identity.foundation/sidetree/spec/v<span class="token tag"><span class="token tag"><span class="token punctuation">&lt;</span>major</span><span class="token punctuation">></span></span>.<span class="token tag"><span class="token tag"><span class="token punctuation">&lt;</span>minor</span><span class="token punctuation">></span></span>.<span class="token tag"><span class="token tag"><span class="token punctuation">&lt;</span>patch</span><span class="token punctuation">></span></span>/
</code></pre>
            <p>Versions of the Sidetree reference implementation are also provided as npm modules and <a
                    href="https://github.com/decentralized-identity/sidetree/releases">GitHub releases</a>:</p>
            <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"name"</span><span class="token operator">:</span> <span class="token string">"@decentralized-identity/sidetree"</span><span class="token punctuation">,</span>
  <span class="token property">"version"</span><span class="token operator">:</span> <span class="token string">"&lt;major>.&lt;minor>.&lt;patch>"</span><span class="token punctuation">,</span>
  ...
</code></pre>
            <h3 id="version-segment-definitions"><a class="toc-anchor" href="#version-segment-definitions">§</a> Version
                Segment Definitions</h3>
            <ul>
                <li><strong>Major:</strong> Major protocol evolution, with breaking protocol advancements so large they
                    warrant incrementing the major version.</li>
                <li><strong>Minor:</strong> Critical updates, protocol forking changes, or security patches that require
                    all nodes to upgrade.</li>
                <li><strong>Patch:</strong> Non-critical changes that do not require nodes to upgrade.</li>
            </ul>
            <h3 id="new-version-activation"><a class="toc-anchor" href="#new-version-activation">§</a> New Version
                Activation</h3>
            <p>New versions of the protocol, or modifications to parameter values by implementers,
                <strong><strong>MUST</strong></strong> be activated at a specified <a href="#ledger-time"><em>Ledger
                        Time</em></a> so all nodes can remain in sync by enforcing the same ruleset and parameters
                beginning at the same logical starting point. All transactions that occur after the specified <a
                    href="#ledger-time"><em>Ledger Time</em></a> will adhere to the associated version’s rules and
                parameters until a newer version of the protocol is defined and implemented at a future <a
                    href="#ledger-time"><em>Ledger Time</em></a>.</p>
            <h2 id="default-parameters"><a class="toc-anchor" href="#default-parameters">§</a> Default Parameters</h2>
            <p>Each version of the protocol will define a set of protocol rules and parameters with default suggested
                values. The following are the parameters used by this version of the Sidetree protocol - implementers
                <strong><strong>MAY</strong></strong> choose different options than the defaults listed below:</p>
            <table>
                <thead>
                    <tr>
                        <th>Protocol Parameter</th>
                        <th>Description</th>
                        <th style="text-align:left">Suggested Defaults</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td id="hash-algorithm"><code>HASH_ALGORITHM</code></td>
                        <td>Algorithm for generating hashes of protocol-related values.</td>
                        <td style="text-align:left">SHA256</td>
                    </tr>
                    <tr>
                        <td id="hash-protocol"><code>HASH_PROTOCOL</code></td>
                        <td>Protocol for generating hash representations in Sidetree implementations, using the <a
                                href="#hash-algorithm"><code>HASH_ALGORITHM</code></a></td>
                        <td style="text-align:left"><a href="#multihash">Multihash</a></td>
                    </tr>
                    <tr>
                        <td id="data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></td>
                        <td>Encoding selected for various data (JSON, hashes, etc.) used within an implementation, the
                            output of which <strong><strong>MUST</strong></strong> be in ASCII format.</td>
                        <td style="text-align:left">Base64URL</td>
                    </tr>
                    <tr>
                        <td id="key-algorithm"><code>KEY_ALGORITHM</code></td>
                        <td>Asymmetric public key algorithm for signing DID operations. Must be a valid JWK
                            <code>crv</code>.</td>
                        <td style="text-align:left">secp256k1</td>
                    </tr>
                    <tr>
                        <td id="sig-algorithm"><code>SIGNATURE_ALGORITHM</code></td>
                        <td>Asymmetric public key signature algorithm. Must be a valid JWS <code>alg</code>.</td>
                        <td style="text-align:left">ES256K</td>
                    </tr>
                    <tr>
                        <td id="cas-protocol"><code>CAS_PROTOCOL</code></td>
                        <td>The CAS network protocol used within an implementation.</td>
                        <td style="text-align:left">IPFS</td>
                    </tr>
                    <tr>
                        <td id="cas-uri-algorithm"><code>CAS_URI_ALGORITHM</code></td>
                        <td>Algorithm for generating unique content-bound identifiers for the implementation-selected
                            CAS protocol</td>
                        <td style="text-align:left">IPFS CID</td>
                    </tr>
                    <tr>
                        <td id="compression-algorithm"><code>COMPRESSION_ALGORITHM</code></td>
                        <td>File compression algorithm</td>
                        <td style="text-align:left">ZIP</td>
                    </tr>
                    <tr>
                        <td id="reveal-value"><code>REVEAL_VALUE</code></td>
                        <td>Cryptographically random value to be revealed in the next operation.</td>
                        <td style="text-align:left">100 bytes</td>
                    </tr>
                    <tr>
                        <td id="genesis-time"><code>GENESIS_TIME</code></td>
                        <td>The point in the target ledger’s transaction history at which Sidetree implementation is
                            first activated (e.g. block number in a blockchain).</td>
                        <td style="text-align:left">630000</td>
                    </tr>
                    <tr>
                        <td id="max-anchor-file-size"><code>MAX_ANCHOR_FILE_SIZE</code></td>
                        <td>Maximum compressed <a href="#anchor-file">Anchor File</a> size.</td>
                        <td style="text-align:left">1 MB</td>
                    </tr>
                    <tr>
                        <td id="max-map-file-size"><code>MAX_MAP_FILE_SIZE</code></td>
                        <td>Maximum compressed map file size.</td>
                        <td style="text-align:left">1 MB</td>
                    </tr>
                    <tr>
                        <td id="max-chunk-file-size"><code>MAX_CHUNK_FILE_SIZE</code> </td>
                        <td>Maximum compressed chunk file size.</td>
                        <td style="text-align:left">10 MB</td>
                    </tr>
                    <tr>
                        <td><code>MAX_ENCODED_HASH_LENGTH</code></td>
                        <td>Maximum accepted string length of an encoded hash.</td>
                        <td style="text-align:left">100 bytes</td>
                    </tr>
                    <tr>
                        <td><code>MAX_OPERATION_SIZE</code></td>
                        <td>Maximum uncompressed operation size.</td>
                        <td style="text-align:left">1 kb</td>
                    </tr>
                    <tr>
                        <td><code>MAX_OPERATION_COUNT</code></td>
                        <td>Maximum number of operations per batch.</td>
                        <td style="text-align:left">10,000</td>
                    </tr>
                </tbody>
            </table>
            <h2 id="common-functions"><a class="toc-anchor" href="#common-functions">§</a> Common Functions</h2>
            <p>The following is a list of functional procedures that are commonly used across the protocol. These
                functions are defined once here and referenced throughout the specification, wherever an implementer
                must invoke them to comply with normative processes.</p>
            <h3 id="hashing-process"><a class="toc-anchor" href="#hashing-process">§</a> Hashing Process</h3>
            <p>All data hashed within the bounds of the protocol follow the same procedural steps, and yield a
                consistently encoded output. Given a data value, the following steps are used to generated a hashed
                output:</p>
            <ol>
                <li>Generate a hash of the data value using the <a href="#hash-protocol"><code>HASH_PROTOCOL</code></a>
                    with the <a href="#hash-algorithm"><code>HASH_ALGORITHM</code></a>.</li>
                <li>Encode the resulting output using the <a
                        href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>.</li>
                <li>Return the encoded hashing output.</li>
            </ol>
            <p>Pseudo-code example using current protocol defaults:</p>
            <pre class="language-js"><code class="language-js"><span class="token keyword">let</span> HashingOutput <span class="token operator">=</span> <span class="token function">Base64URL</span><span class="token punctuation">(</span> <span class="token function">Multihash</span><span class="token punctuation">(</span><span class="token constant">DATA</span><span class="token punctuation">,</span> <span class="token string">'sha2-256'</span><span class="token punctuation">)</span> <span class="token punctuation">)</span><span class="token punctuation">;</span>
</code></pre>
            <h3 id="commitment-schemes"><a class="toc-anchor" href="#commitment-schemes">§</a> Commitment Schemes</h3>
            <p><a href="#commitment-scheme">Commitment schemes</a> are used by the Sidetree protocol in important ways
                to preserve the integrity of operations and assist in recovery.</p>
            <h4 id="public-key-commitment-scheme"><a class="toc-anchor" href="#public-key-commitment-scheme">§</a>
                Public Key Commitment Scheme</h4>
            <p>The following steps define the <a href="#commitment-scheme">commitment scheme</a> for generating a <a
                    href="#public-key-commitment">public key commitment</a> from a public key.</p>
            <ol>
                <li>Encode the public key into the form of a valid <a
                        href="https://tools.ietf.org/html/rfc7517">JWK</a>.</li>
                <li>Canonicalize the <a href="https://tools.ietf.org/html/rfc7517">JWK</a> encoded public key using the
                    <a href="https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17">JSON
                        Canonicalization Scheme</a>.</li>
                <li>Apply the defined <a href="#hash-algorithm">HASH_ALGORITHM</a> to the canonicalized public key to
                    produce the <a href="#public-key-commitment">public key commitment</a>.</li>
            </ol>
            <p>Implementers <strong><strong>MUST NOT</strong></strong> re-use public keys across different commitment
                invocations.</p>
            <h2 id="network-topology"><a class="toc-anchor" href="#network-topology">§</a> Network Topology</h2>
            <p>The figure below illustrates the three primary components of a Sidetree-based DID overlay network:</p>
            <ol>
                <li>The underlying ledger system that serves as the global anchoring and linear sequencing system for
                    DID operations.</li>
                <li>The Sidetree nodes themselves, which interact with the ledger system to anchor operations, fetch and
                    replicate data from the CAS network, and process operations in accordance with the protocol
                    deterministic ruleset.</li>
                <li>An integrated Content-Addressable Storage (CAS) network layer Sidetree nodes use to distribute and
                    replicate DID operation files.</li>
            </ol>
            <img src="../diagrams/sidetree-system.svg"
                style="display: block; margin: 0 auto; padding: 1em 0; width: 100%; max-width: 620px;" />
            <h2 id="file-structures"><a class="toc-anchor" href="#file-structures">§</a> File Structures</h2>
            <p>The protocol defines the following three file structures, which house DID operation data and are designed
                to support key functionality to enable light node configurations, minimize permanently retained data,
                and ensure performant resolution of DIDs.</p>
            <img src="../diagrams/file-topology.svg"
                style="display: block; margin: 0 auto; padding: 2em 0; width: 100%; max-width: 620px;" />
            <h3 id="anchor-file"><a class="toc-anchor" href="#anchor-file">§</a> Anchor File</h3>
            <p>Anchor Files contain <a href="#create">Create</a>, <a href="#recover">Recover</a>, and <a
                    href="#deactivate">Deactivate</a> operation values, as well as a CAS URI for the related Sidetree
                Map file (detailed below). As the name suggests, Anchor Files are anchored to the target ledger system
                via embedding a CAS URI in the ledger’s transactional history.</p>
            <div id="example-7" class="notice example"><a class="notice-link" href="#example-7">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"map_file_uri"</span><span class="token operator">:</span> CAS_URI<span class="token punctuation">,</span>
  <span class="token property">"writer_lock_id"</span><span class="token operator">:</span> OPTIONAL_LOCKING_VALUE<span class="token punctuation">,</span>
  <span class="token property">"operations"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
    <span class="token property">"create"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
      <span class="token punctuation">{</span>
        <span class="token property">"suffix_data"</span><span class="token operator">:</span> <span class="token punctuation">{</span> <span class="token comment">// Base64URL encoded</span>
          <span class="token property">"delta_hash"</span><span class="token operator">:</span> DELTA_HASH<span class="token punctuation">,</span>
          <span class="token property">"recovery_commitment"</span><span class="token operator">:</span> COMMITMENT_HASH
        <span class="token punctuation">}</span>
      <span class="token punctuation">}</span><span class="token punctuation">,</span>
      <span class="token punctuation">{</span>...<span class="token punctuation">}</span>
    <span class="token punctuation">]</span><span class="token punctuation">,</span>
    <span class="token property">"recover"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
      <span class="token punctuation">{</span>
        <span class="token property">"did_suffix"</span><span class="token operator">:</span> SUFFIX_STRING<span class="token punctuation">,</span>
        <span class="token property">"signed_data"</span><span class="token operator">:</span> <span class="token punctuation">{</span> <span class="token comment">// Base64URL encoded, compact JWS</span>
          <span class="token property">"protected"</span><span class="token operator">:</span> <span class="token punctuation">{</span>...<span class="token punctuation">}</span><span class="token punctuation">,</span>
          <span class="token property">"payload"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
            <span class="token property">"recovery_commitment"</span><span class="token operator">:</span> COMMITMENT_HASH<span class="token punctuation">,</span>
            <span class="token property">"recovery_key"</span><span class="token operator">:</span> JWK_OBJECT<span class="token punctuation">,</span>
            <span class="token property">"delta_hash"</span><span class="token operator">:</span> DELTA_HASH
          <span class="token punctuation">}</span><span class="token punctuation">,</span>
          <span class="token property">"signature"</span><span class="token operator">:</span> SIGNATURE_STRING
        <span class="token punctuation">}</span>
      <span class="token punctuation">}</span><span class="token punctuation">,</span>
      <span class="token punctuation">{</span>...<span class="token punctuation">}</span>
    <span class="token punctuation">]</span><span class="token punctuation">,</span>
    <span class="token property">"deactivate"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
      <span class="token punctuation">{</span>
        <span class="token property">"did_suffix"</span><span class="token operator">:</span> SUFFIX_STRING<span class="token punctuation">,</span>
        <span class="token property">"signed_data"</span><span class="token operator">:</span> <span class="token punctuation">{</span> <span class="token comment">// Base64URL encoded, compact JWS</span>
            <span class="token property">"protected"</span><span class="token operator">:</span> <span class="token punctuation">{</span>...<span class="token punctuation">}</span><span class="token punctuation">,</span>
            <span class="token property">"payload"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
              <span class="token property">"did_suffix"</span><span class="token operator">:</span> SUFFIX_STRING<span class="token punctuation">,</span>
              <span class="token property">"recovery_key"</span><span class="token operator">:</span> JWK_OBJECT
            <span class="token punctuation">}</span><span class="token punctuation">,</span>
            <span class="token property">"signature"</span><span class="token operator">:</span> SIGNATURE_STRING
        <span class="token punctuation">}</span>
      <span class="token punctuation">}</span><span class="token punctuation">,</span>
      <span class="token punctuation">{</span>...<span class="token punctuation">}</span>
    <span class="token punctuation">]</span>
  <span class="token punctuation">}</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <p>A valid <a href="#anchor-file">Anchor File</a> is a JSON document that <strong><strong>MUST
                        NOT</strong></strong> exceed the <a
                    href="#max-anchor-file-size"><code>MAX_ANCHOR_FILE_SIZE</code></a>, and composed as follows:</p>
            <ol>
                <li>The <a href="#anchor-file">Anchor File</a> <strong><strong>MUST</strong></strong> contain a <a
                        href="#map-file-property" id="map-file-property"><code>map_file_uri</code></a> property if the
                    batch of transactions being anchored contains any Create, Recovery, or Update operations, and its
                    value <strong><strong>MUST</strong></strong> be a <em>CAS URI</em> for the related Map File. If the
                    batch of transactions being anchored is only comprised of Deactivate operations, the <a
                        href="#map-file-property"><code>map_file_uri</code></a> property <strong><strong>MUST
                            NOT</strong></strong> be present.</li>
                <li>The <a href="#anchor-file">Anchor File</a> <strong><strong>MAY</strong></strong> contain a <a
                        href="#writer-lock-property" id="writer-lock-property"><code>writer_lock_id</code></a> if the
                    implementation chooses to implement a value locking scheme for economically based network
                    protection, and its value <strong><strong>MUST</strong></strong> be defined by the implementation to
                    reflect whatever values the are required to facilitate the necessary ledger and operation-level
                    evaluations.</li>
                <li>If the set of operations to be anchored contain any <a href="#create">Create</a>, <a
                        href="#recover">Recover</a>, or <a href="#deactivate">Deactivate</a> operations, the <a
                        href="#anchor-file">Anchor File</a> <strong><strong>MUST</strong></strong> contain an
                    <code>operations</code> property, and its value <strong><strong>MUST</strong></strong> be an object
                    composed as follows:
                    <ul>
                        <li>If there are any <a href="#create">Create</a> operations to be included in the Anchor File:
                            <ol>
                                <li>The <code>operations</code> object <strong><strong>MUST</strong></strong> include a
                                    <code>create</code> property, and its value <strong><strong>MUST</strong></strong>
                                    be an array.</li>
                                <li>For each <a href="#create">Create</a> operation to be included in the
                                    <code>create</code> array, herein referred to as <a href="#anchor-file-create-entry"
                                        id="anchor-file-create-entry"><em>Anchor File Create Entries</em></a>, use the
                                    following process to compose and include a JSON object for each entry:
                                    <ul>
                                        <li>Each object must contain a <code>suffix_data</code> property, and its value
                                            <strong><strong>MUST</strong></strong> be a <a
                                                href="#create-suffix-data-object"><em>Create Operation Suffix Data
                                                    Object</em></a>.</li>
                                    </ul>
                                </li>
                                <li>The <a href="#anchor-file">Anchor File</a> <strong><strong>MUST
                                            NOT</strong></strong> include multiple <a href="#create">Create</a>
                                    operations that produce the same <a href="#did-suffix">DID Suffix</a>.</li>
                            </ol>
                        </li>
                        <li>If there are any <a href="#recover">Recovery</a> operations to be included in the Anchor
                            File:
                            <ol>
                                <li>The <code>operations</code> object <strong><strong>MUST</strong></strong> include a
                                    <code>recover</code> property, and its value <strong><strong>MUST</strong></strong>
                                    be an array.</li>
                                <li>For each <a href="#recover">Recovery</a> operation to be included in the
                                    <code>recover</code> array, herein referred to as <a
                                        href="#anchor-file-recovery-entry" id="anchor-file-recovery-entry"><em>Anchor
                                            File Recovery Entries</em></a>, use the following process to compose and
                                    include entries:
                                    <ul>
                                        <li>The object <strong><strong>MUST</strong></strong> contain a
                                            <code>did_suffix</code> property, and its value
                                            <strong><strong>MUST</strong></strong> be the <a href="#did-suffix">DID
                                                Suffix</a> of the DID the operation pertains to. An <a
                                                href="#anchor-file">Anchor File</a> <strong><strong>MUST
                                                    NOT</strong></strong> contain more than one operation of any type
                                            with the same <a href="#did-suffix">DID Suffix</a>.</li>
                                        <li>The object <strong><strong>MUST</strong></strong> contain a
                                            <code>signed_data</code> property, and its value
                                            <strong><strong>MUST</strong></strong> be a <a
                                                href="#recovery-signed-data-object"><em>Recovery Operation Signed Data
                                                    Object</em></a>.</li>
                                    </ul>
                                </li>
                            </ol>
                        </li>
                        <li>If there are any <a href="#deactivate">Deactivate</a> operations to be included in the
                            Anchor File:
                            <ol>
                                <li>The <code>operations</code> object <strong><strong>MUST</strong></strong> include a
                                    <code>deactivate</code> property, and its value
                                    <strong><strong>MUST</strong></strong> be an array.</li>
                                <li>For each <a href="#deactivate">Deactivate</a> operation to be included in the
                                    <code>deactivate</code> array, use the following process to compose and include
                                    entries:
                                    <ul>
                                        <li>The object <strong><strong>MUST</strong></strong> contain a
                                            <code>did_suffix</code> property, and its value
                                            <strong><strong>MUST</strong></strong> be the <a href="#did-suffix">DID
                                                Suffix</a> of the DID the operation pertains to. An <a
                                                href="#anchor-file">Anchor File</a> <strong><strong>MUST
                                                    NOT</strong></strong> contain more than one operation of any type
                                            with the same <a href="#did-suffix">DID Suffix</a>.</li>
                                        <li>The object <strong><strong>MUST</strong></strong> contain a
                                            <code>signed_data</code> property, and its value
                                            <strong><strong>MUST</strong></strong> be a <a
                                                href="#deactivate-signed-data-object"><em>Deactivate Operation Signed
                                                    Data Object</em></a>.</li>
                                    </ul>
                                </li>
                            </ol>
                        </li>
                    </ul>
                </li>
            </ol>
            <h3 id="map-file"><a class="toc-anchor" href="#map-file">§</a> Map File</h3>
            <p>Map Files contain <a href="#update">Update</a> operation proving data, as well as CAS URI links to <a
                    href="#chunk-files">Chunk Files</a>.</p>
            <div id="example-8" class="notice example"><a class="notice-link" href="#example-8">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"chunks"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
    <span class="token punctuation">{</span> <span class="token property">"chunk_file_uri"</span><span class="token operator">:</span> CHUNK_HASH <span class="token punctuation">}</span><span class="token punctuation">,</span>
    <span class="token punctuation">{</span>...<span class="token punctuation">}</span>
  <span class="token punctuation">]</span><span class="token punctuation">,</span>
  <span class="token property">"operations"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
    <span class="token property">"update"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
      <span class="token punctuation">{</span>
        <span class="token property">"did_suffix"</span><span class="token operator">:</span> DID_SUFFIX<span class="token punctuation">,</span>
        <span class="token property">"signed_data"</span><span class="token operator">:</span> <span class="token punctuation">{</span> <span class="token comment">// Base64URL encoded, compact JWS</span>
            <span class="token property">"protected"</span><span class="token operator">:</span> <span class="token punctuation">{</span>...<span class="token punctuation">}</span><span class="token punctuation">,</span>
            <span class="token property">"payload"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
              <span class="token property">"update_key"</span><span class="token operator">:</span> JWK_OBJECT<span class="token punctuation">,</span>
              <span class="token property">"delta_hash"</span><span class="token operator">:</span> DELTA_HASH
            <span class="token punctuation">}</span><span class="token punctuation">,</span>
            <span class="token property">"signature"</span><span class="token operator">:</span> SIGNATURE_STRING
        <span class="token punctuation">}</span>   
      <span class="token punctuation">}</span><span class="token punctuation">,</span>
      <span class="token punctuation">{</span>...<span class="token punctuation">}</span>
    <span class="token punctuation">]</span>
  <span class="token punctuation">}</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <p>A valid <a href="#map-file">Map File</a> is a JSON document that <strong><strong>MUST
                        NOT</strong></strong> exceed the <a
                    href="#max-map-file-size"><code>MAX_MAP_FILE_SIZE</code></a>, and composed as follows:</p>
            <ol>
                <li>The <a href="#map-file">Map File</a> <strong><strong>MUST</strong></strong> contain a
                    <code>chunks</code> property, and its value <strong><strong>MUST</strong></strong> be an array of
                    <em>Chunk Entries</em> for the related delta data for a given chunk of operations in the batch.
                    Future versions of the protocol will specify a process for separating the operations in a batch into
                    multiple <em>Chunk Entries</em>, but for this version of the protocol there
                    <strong><strong>MUST</strong></strong> be only one <em>Chunk Entry</em> present in the array.
                    <em>Chunk Entry</em> objects are composed as follows:
                    <ol>
                        <li>The <em>Chunk Entry</em> object <strong><strong>MUST</strong></strong> contain a
                            <code>chunk_file_uri</code> property, and its value <strong><strong>MUST</strong></strong>
                            be a URI representing the corresponding CAS file entry, generated via the <a
                                href="#cas-uri-algorithm"><code>CAS_URI_ALGORITHM</code></a>.</li>
                    </ol>
                </li>
                <li>If there are any <a href="#update">Update</a> operations to be included in the Map File, the <a
                        href="#map-file">Map File</a> <strong><strong>MUST</strong></strong> include an
                    <code>operations</code> property, and its value <strong><strong>MUST</strong></strong> be an object
                    composed as follows:
                    <ol>
                        <li>The <code>operations</code> object <strong><strong>MUST</strong></strong> include an
                            <code>update</code> property, and its value <strong><strong>MUST</strong></strong> be an
                            array.</li>
                        <li>For each <a href="#update">Update</a> operation to be included in the <code>update</code>
                            array, herein referred to as <a href="#map-file-update-entry" id="map-file-update-entry">Map
                                File Update Entries</a>, use the following process to compose and include entries:
                            <ul>
                                <li>The object <strong><strong>MUST</strong></strong> contain an <code>did_suffix</code>
                                    property, and its value <strong><strong>MUST</strong></strong> be the <a
                                        href="#did-suffix">DID Suffix</a> of the DID the operation pertains to.</li>
                                <li>The object <strong><strong>MUST</strong></strong> contain a <code>signed_data</code>
                                    property, and its value <strong><strong>MUST</strong></strong> be an <a
                                        href="#update-signed-data-object"><em>Update Operation Signed Data
                                            Object</em></a>.</li>
                            </ul>
                        </li>
                    </ol>
                </li>
            </ol>
            <h3 id="chunk-files"><a class="toc-anchor" href="#chunk-files">§</a> Chunk Files</h3>
            <p>Chunk Files are JSON Documents, compressed via the <a
                    href="#compression-algorithm">COMPRESSION_ALGORITHM</a> contain Sidetree Operation source data,
                which are composed of delta-based CRDT entries that modify the state of a Sidetree identifier’s DID
                Document.</p>
            <p>For this version of the protocol, there will only exist a single Chunk File that contains all the state
                modifying data for all operations in the included set. Future versions of the protocol will separate the
                total set of included operations into multiple chunks, each with their own Chunk File.</p>
            <div id="create-operation-chunk-file-entry" class="notice example"><a class="notice-link"
                    href="#create-operation-chunk-file-entry">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"deltas"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
       
    <span class="token punctuation">{</span> <span class="token comment">// JSON.stringify()-ed, and Base64URL encoded</span>
      <span class="token property">"patches"</span><span class="token operator">:</span> PATCH_ARRAY<span class="token punctuation">,</span>
      <span class="token property">"update_commitment"</span><span class="token operator">:</span> COMMITMENT_HASH
    <span class="token punctuation">}</span><span class="token punctuation">,</span>
    ...
  <span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <p>In this version of the protocol, Chunk Files are constructed as follows:</p>
            <ol>
                <li>
                    <p>The Chunk File <strong><strong>MUST</strong></strong> include a <code>deltas</code> property, and
                        its value <strong><strong>MUST</strong></strong> be an array containing <a
                            href="#chunk-file-delta-entry" id="chunk-file-delta-entry"><em>Chunk File Delta
                                Entry</em></a> objects.</p>
                </li>
                <li>
                    <p>Each <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>
                        <strong><strong>MUST</strong></strong> be a <code>Base64URL</code> encoded object, assembled as
                        follows:</p>
                    <ol>
                        <li>The object <strong><strong>MUST</strong></strong> contain a <code>patches</code> property,
                            and its value <strong><strong>MUST</strong></strong> be an array of <a
                                href="#did-state-patches">DID State Patches</a>.</li>
                        <li>The payload <strong><strong>MUST</strong></strong> contain an <code>update_commitment</code>
                            property, and its value <strong><strong>MUST</strong></strong> be the next <em>Update
                                Commitment</em> generated during the operation process associated with the type of
                            operation being performed.</li>
                    </ol>
                </li>
                <li>
                    <p>Each <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>
                        <strong><strong>MUST</strong></strong> be appended to the <code>deltas</code> array as follows,
                        in this order:</p>
                    <ol>
                        <li>If any Create operations were present in the associated Anchor File, append all <a
                                href="#create-delta-object"><em>Create Operation Delta Objects</em></a> in the same
                            index order as their matching <a href="#anchor-file-create-entry"><em>Anchor File Create
                                    Entry</em></a>.</li>
                        <li>If any Recovery operations were present in the associated Anchor File, append all <a
                                href="#recovery-delta-object"><em>Recovery Operation Delta Objects</em></a> in the same
                            index order as their matching <a href="#anchor-file-recovery-entry"><em>Anchor File Recovery
                                    Entry</em></a>.</li>
                        <li>If any Update operations were present in the associated Map File, append all <a
                                href="#update-delta-object"><em>Update Operation Delta Objects</em></a> in the same
                            index order as their matching <a href="#map-file-update-entry"><em>Map File Update
                                    Entry</em></a>.</li>
                    </ol>
                </li>
            </ol>
            <h2 id="did-uri-composition"><a class="toc-anchor" href="#did-uri-composition">§</a> DID URI Composition
            </h2>
            <p>DID Methods based on the Sidetree protocol all share the same identifier format. The unique identifier
                segment of a Sidetree-based DID, known as the <a href="#did-suffix">DID Suffix</a>, is derived by using
                the <a href="#hashing-process">Hashing Process</a> to generate a hash value from the decoded <a
                    href="#create-suffix-data-object"><em>Create Operation Suffix Data Object</em></a>. The <a
                    href="#did-suffix">DID Suffix</a> is cryptographically bound to the initial PKI state of the DID,
                which means Sidetree DIDs are <em>self-certifying</em>. As a result, a person or entity who creates a
                Sidetree-based DID knows their unique identifier at the moment of generation, and it is cryptographic
                secured for instant use (for more on the instant use capabilities of Sidetree DIDs, see <a
                    href="#unpublished-did-resolution">Unpublished DID Resolution</a>).</p>
            <p>To generate the <a href="#short-form-did" id="short-form-did"><em>Short-Form DID URI</em></a> of a
                Sidetree DID, use the <a href="#hashing-process">Hashing Process</a> to generate a hash of the decoded
                <a href="#create-suffix-data-object"><em>Create Operation Suffix Data Object</em></a>. The following is
                an example of a resulting colon (<code>:</code>) separated DID URI composed of the URI scheme
                (<code>did:</code>), Method identifier (<code>sidetree:</code>), and unique identifier string
                (<code>EiBJz4...</code>):</p>
            <pre class="language-css"><code class="language-css"><span class="token property">did</span><span class="token punctuation">:</span><span class="token property">sidetree</span><span class="token punctuation">:</span>EiBJz4qd3Lvof3boqBQgzhMDYXWQ_wZs67jGiAhFCiQFjw
</code></pre>
            <h3 id="long-form-did-uris"><a class="toc-anchor" href="#long-form-did-uris">§</a> Long-Form DID URIs</h3>
            <p>DID URI strings may include additional values that are used in resolution and other activities. The
                standard way to pass these values are through <em>DID URL Parameters</em>, as defined by the <a
                    href="https://w3c.github.io/did-core/">W3C Decentralized Identifiers</a> specification.</p>
            <p>Many DID Methods require a period of time (which may be indefinite) between the generation of a DID and
                the DID being anchored/propagated in the underlying ledger system, and other layers for which
                propagation delays may apply. Sidetree introduces the <code>initial-state</code> <em>DID URL
                    Parameter</em> to enable resolution of unpropagated and unpublished DIDs. To use a Sidetree-based
                DID immediately after generation, the controller <strong><strong>MUST</strong></strong> include the
                <code>initial-state</code> <em>DID URL Parameter</em> in the DID URI string, with the value being a
                string composed of the <a href="#create-suffix-data-object"><em>Create Operation Suffix Data
                        Object</em></a> and the <a href="#create-delta-object"><em>Create Operation Delta
                        Object</em></a>, separated by a period (<code>.</code>), as follows:</p>
            <pre class="language-html"><code class="language-html">did:METHOD:<span class="token tag"><span class="token tag"><span class="token punctuation">&lt;</span>did-suffix</span><span class="token punctuation">></span></span>?initial-state=<span class="token tag"><span class="token tag"><span class="token punctuation">&lt;</span>create-suffix-data-object</span><span class="token punctuation">></span></span>.<span class="token tag"><span class="token tag"><span class="token punctuation">&lt;</span>create-delta-object</span><span class="token punctuation">></span></span>
</code></pre>
            <p>This <em>DID URL Parameter</em> mechanism of conveying the initial <em>self-certifying</em> state of a
                DID, known as the <a href="#long-form-did" id="long-form-did"><em>Long-Form DID URI</em></a> supports
                the following features and usage patterns:</p>
            <ul>
                <li>Resolving the DID Documents of unpublished DIDs.</li>
                <li>Authenticating with unpublished DIDs.</li>
                <li>Signing and verifying credentials signed against unpublished DIDs.</li>
                <li>After publication and propagation are complete, authenticating with either the <a
                        href="#short-form-did"><em>Short-Form DID URI</em></a> or <a href="#long-form-did"><em>Long-Form
                            DID URI</em></a>.</li>
                <li>After publication and propagation are complete, signing and verifying credentials signed against
                    either the <a href="#short-form-did"><em>Short-Form DID URI</em></a> or <a
                        href="#long-form-did"><em>Long-Form DID URI</em></a>.</li>
            </ul>
            <h2 id="json-web-signatures"><a class="toc-anchor" href="#json-web-signatures">§</a> JSON Web Signatures
            </h2>
            <p>Sidetree relies on JSON Web Signatures for authentication and integrity protection of <a
                    href="https://identity.foundation/sidetree/spec/#did-operations">DID Operations</a>, accept for
                Create, with contains key material and is self certifying.</p>
            <h3 id="signing"><a class="toc-anchor" href="#signing">§</a> Signing</h3>
            <p>In addition to <a href="https://tools.ietf.org/html/rfc7515">RFC7515</a>, the following additional
                requirements MUST be observed by Sidetree Method implementeers.</p>
            <ol>
                <li><code>kid</code> MUST be present in the protected header.</li>
                <li><code>alg</code> MUST be present in the protected header, its value MUST NOT be none.</li>
                <li>No additional members may be present in the protected header.</li>
            </ol>
            <p>Here is an example of a decoded JWS header:</p>
            <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"kid"</span><span class="token operator">:</span> <span class="token string">"did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"</span><span class="token punctuation">,</span>
  <span class="token property">"alg"</span><span class="token operator">:</span> <span class="token string">"EdDSA"</span>
<span class="token punctuation">}</span>
</code></pre>
            <div id="warning-1" class="notice warning"><a class="notice-link" href="#warning-1">WARNING</a>
                <p>It is recommended that <code>kid</code> be a DID URL. If it is not, method implementers might need to
                    rely on additional context to uniquely identify the associated verificationMethod.</p>
            </div>
            <h3 id="verifying"><a class="toc-anchor" href="#verifying">§</a> Verifying</h3>
            <p>Regardless of which verification relationship a verificationMethod is associated with, the process of
                verifying a JWS linked to a DID is the same.</p>
            <p>The JWS header is parsed and a <code>kid</code> is extracted.</p>
            <ol>
                <li>Iterate the verificationMethods, until a verificationMethod with <code>id</code> equal to
                    <code>kid</code> is found.</li>
                <li>Convert the discovered verificationMethod to JWK if necessary.</li>
                <li>Perform <a href="https://tools.ietf.org/html/rfc7515#section-5.2">JWS Verification</a> using the
                    JWK.</li>
            </ol>
            <h4 id="operation-verification"><a class="toc-anchor" href="#operation-verification">§</a> Operation
                Verification</h4>
            <p>Sidetree operations are considered valid when the JWS can be verified, and where the verificationMethod
                used is associated with the correct verification relationship.</p>
            <p><code>operation</code>, <code>recovery</code> are verification relationships for verifying sidetree
                operations which sidetree DID Methods MUST support, and which MAY be exposed externally via the DID
                Document or Resolver Method Meta Data.</p>
            <p>An <a href="https://identity.foundation/sidetree/spec/#update">Update Operation</a> MUST be signed by an
                <a href="#operation-key-pair">Operation Key Pair</a> that is authorized for an update operation. The
                public key of this key pair or a commitment to the public key MAY be exposed in the DID Document or
                Resolver Meta Data, and MAY be associated with an <code>operation</code> verification relationship.</p>
            <p>A <a href="https://identity.foundation/sidetree/spec/#recover">Recover Operation</a> MUST by signed by <a
                    href="#recovery-key-pair">Recovery Key Pair</a> that is authorized for a recovery operation. The
                public key of this key pair or a commitment to the public key MAY be exposed in the DID Document or
                Resolver Meta Data, and MAY be associated with a <code>recovery</code> verification relationship.</p>
            <p>A <a href="https://identity.foundation/sidetree/spec/#deactivate">Deactivate Operation</a> MUST by signed
                by <a href="#recovery-key-pair">Recovery Key Pair</a> that is authorized for a recovery operation. The
                public key of this key pair or a commitment to the public key MAY be exposed in the DID Document or
                Resolver Meta Data, and MAY be associated with a <code>recovery</code> verification relationship.</p>
            <p>If a verificationMethod with <code>id</code> matching the JWS <code>kid</code> is not present in the
                expected collection, the sidetree operation is considered not valid.</p>
            <div id="warning-2" class="notice warning"><a class="notice-link" href="#warning-2">WARNING</a>
                <p>Operations may be verified, and yet still rejected in the resolution process.</p>
            </div>
            <p>DID Core also defines verification relationships which sidetree DID Methods MAY support.</p>
            <p><code>assertionMethod</code> for use with Verifiable Credentials.
                <code>authentication</code> for use with Verifiable Presentations, and general authentication flows.
                <code>capabilityInvocation</code> and <code>capabilityDelegation</code> for use with Object Capabilities
                used by Secure Data Stores / Encrypted Data vaults.</p>
            <p><em>Operation Key</em> and <em>Recovery Key</em> public key representations MAY be present in any
                verification relationship.</p>
            <div id="warning-3" class="notice warning"><a class="notice-link" href="#warning-3">WARNING</a>
                <p>verificationMethod objects can be embedded, or referenced by <code>id</code>.</p>
            </div>
            <div id="warning-4" class="notice warning"><a class="notice-link" href="#warning-4">WARNING</a>
                <p>verificationMethod <code>id</code> can be a pure fragment, such as <code>#key-0</code> or a well
                    formed URI, such as <code>did:example:123#key-1</code>. The later is much more common, and the
                    former may lead to interoperability issues.</p>
            </div>
            <div id="warning-5" class="notice warning"><a class="notice-link" href="#warning-5">WARNING</a>
                <p>It is not recommended to reuse verificationMethods for multiple verification relationships.</p>
            </div>
            <h2 id="did-operations"><a class="toc-anchor" href="#did-operations">§</a> DID Operations</h2>
            <p>Sidetree-based DIDs support a variety of DID operations, all of which require the DID owner to generate
                specific data values and cryptographic material. The sections below describe how to perform each type of
                operation, and how those operations are represented in the CAS-replicated files that are anchored to the
                underlying ledger system.</p>
            <p>While virtually all DID owners will engage User Agent applications on their local devices to perform
                these operations, most will not generate the anchoring transactions on the underlying ledger. Instead,
                most users will likely send the anchoring-related operation values they generate to external nodes for
                anchoring. This is relatively safe, because operations require signatures that an external node cannot
                forge. The only attack available to a rogue node operator is to not anchor the operations a DID owner
                sends them. However, the DID owner can detect this (via a scan of subsequent blocks) and send their
                operation to a different node or do it themselves, if they so desire.</p>
            <div id="note-1" class="notice note"><a class="notice-link" href="#note-1">NOTE</a>
                <p>This specification does not define an API for sending public DID operation values to third-party
                    Sidetree nodes for external anchoring, as that is an elective activity has no bearing on the
                    technical workings of the protocol, its capabilities, or its security guarantees.</p>
            </div>
            <p>Sidetree Methods MAY choose to expose protocol operation keys in the DID Document.</p>
            <p>Sidetree Methods MAY rely on the DID Document data model when verifying protocol operations.</p>
            <div id="warning-6" class="notice warning"><a class="notice-link" href="#warning-6">WARNING</a>
                <p>Operations other than Create contain a compact JWS. Dereferencing of key material used to verify the
                    JWS is a DID Method specific concern. Some methods may rely of the DID Document data model, others
                    may rely on an internal data model. Some methods may rely on <code>kid</code> of the form
                    <code>did:example:123#fingerprint</code>, others may not include a <code>kid</code> in the JWS, or
                    its value may be arbitrary. Support for specific <code>alg</code> fields is also DID Method
                    specific. Implementers are cautioned to choose support for specific <code>alg</code> values
                    carefully.</p>
            </div>
            <h3 id="create"><a class="toc-anchor" href="#create">§</a> Create</h3>
            <p>Use the following process to generate a Sidetree-based DID:</p>
            <ol>
                <li>Generate a key pair using the defined <a href="#key-algorithm"><code>KEY_ALGORITHM</code></a>, let
                    this be known as the <a href="#operation-key-pair">operation key pair</a>.</li>
                <li>Generate a <a href="#public-key-commitment">public key commitment</a> using the defined <a
                        href="#public-key-commitment-scheme">public key commitment scheme</a> and public key of the
                    generated <a href="#operation-key-pair">operation key pair</a>, let this resulting commitment be
                    known as the <a href="#update-commitment">update commitment</a>.</li>
                <li>Generate an encoded representation of the following object using the implementation’s <a
                        href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>, herein referred to as the <a
                        href="#create-delta-object" id="create-delta-object"><em>Create Operation Delta Object</em></a>:
                    <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"patches"</span><span class="token operator">:</span> <span class="token punctuation">[</span> PATCH_<span class="token number">1</span><span class="token punctuation">,</span> PATCH_<span class="token number">2</span><span class="token punctuation">,</span> ... <span class="token punctuation">]</span><span class="token punctuation">,</span>
  <span class="token property">"update_commitment"</span><span class="token operator">:</span> Update Operation Commitment
<span class="token punctuation">}</span>
</code></pre>
                    <ul>
                        <li>The object <strong><strong>MUST</strong></strong> contain a <code>patches</code> property,
                            and its value <strong><strong>MUST</strong></strong> be a JSON array of <a
                                href="#did-state-patches">DID State Patches</a>.</li>
                        <li>The object <strong><strong>MUST</strong></strong> contain an <code>update_commitment</code>
                            property, and its value <strong><strong>MUST</strong></strong> be the <a
                                href="#update-commitment">update commitment</a> as generated in step 2.</li>
                    </ul>
                </li>
                <li>Generate a key pair using the defined <a href="#key-algorithm"><code>KEY_ALGORITHM</code></a>, let
                    this be known as the <a href="#recovery-key-pair">recovery key pair</a>, where the public key of
                    this pair is used for generating the <a href="#recovery-commitment">recovery commitment</a>, and the
                    private key for use in the next <a href="#recovery">recovery</a> operation.</li>
                <li>Generate a <a href="#public-key-commitment">public key commitment</a> using the defined <a
                        href="#public-key-commitment-scheme">public key commitment scheme</a> and public key of the
                    generated <a href="#recovery-key-pair">recovery key pair</a>, let this resulting commitment be known
                    as the <a href="#recovery-commitment">recovery commitment</a>.</li>
                <li>Generate an encoded representation of the following object using the implementation’s <a
                        href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>, herein referred to as the <a
                        href="#create-suffix-data-object" id="create-suffix-data-object"><em>Create Operation Suffix
                            Data Object</em></a>:
                    <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"delta_hash"</span><span class="token operator">:</span> DELTA_HASH<span class="token punctuation">,</span>
  <span class="token property">"recovery_commitment"</span><span class="token operator">:</span> Recovery Commitment
<span class="token punctuation">}</span>
</code></pre>
                    <ul>
                        <li>The object <strong><strong>MUST</strong></strong> contain a <code>delta_hash</code>
                            property, and its value <strong><strong>MUST</strong></strong> be a hash of the decoded <a
                                href="#create-delta-object"><em>Create Operation Delta Object</em></a> (detailed above),
                            generated via the <a href="#hashing-process">Hashing Process</a>.</li>
                        <li>The object <strong><strong>MUST</strong></strong> contain a <code>recovery_commitment</code>
                            property, and its value <strong><strong>MUST</strong></strong> be the <a
                                href="#recovery-commitment">recovery commitment</a> as generated in step 2.</li>
                    </ul>
                </li>
            </ol>
            <div id="note-2" class="notice note"><a class="notice-link" href="#note-2">NOTE</a>
                <p>Implementations <strong><strong>MAY</strong></strong> choose to define additional properties for
                    inclusion in the <a href="#create-suffix-data-object"><em>Create Operation Suffix Data
                            Object</em></a>, but the presence of any properties beyond the standard properties or
                    implementation-defined properties <strong><strong>ARE NOT</strong></strong> permitted.</p>
            </div>
            <div id="note-3" class="notice note"><a class="notice-link" href="#note-3">NOTE</a>
                <p>Implementers <strong><strong>MAY</strong></strong> choose to canonicalize their <a
                        href="#create-suffix-data-object"><em>Create Operation Suffix Data Objects</em></a> prior
                    applying the <a href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>. This does not
                    affect the outcome or other components in the system that deal with this object.</p>
            </div>
            <h3 id="update"><a class="toc-anchor" href="#update">§</a> Update</h3>
            <p>The following process must be used to update the state a Sidetree-based DID:</p>
            <ol>
                <li>Retrieve the <em>Update Reveal Value</em> that matches the previously anchored <em>Update
                        Commitment</em>.</li>
                <li>Generate an encoded representation of the following object using the implementation’s <a
                        href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>, herein referred to as the <a
                        href="#update-delta-object" id="update-delta-object"><em>Update Operation Delta Object</em></a>,
                    composed as follows:
                    <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"patches"</span><span class="token operator">:</span> <span class="token punctuation">[</span> PATCH_<span class="token number">1</span><span class="token punctuation">,</span> PATCH_<span class="token number">2</span><span class="token punctuation">,</span> ... <span class="token punctuation">]</span><span class="token punctuation">,</span>
  <span class="token property">"update_commitment"</span><span class="token operator">:</span> Update Operation Commitment
<span class="token punctuation">}</span>
</code></pre>
                    <ul>
                        <li>The object <strong><strong>MUST</strong></strong> contain a <code>patches</code> property,
                            and its value <strong><strong>MUST</strong></strong> be an array of <a
                                href="#did-state-patches">DID State Patches</a>.</li>
                        <li>The object <strong><strong>MUST</strong></strong> contain a <code>update_commitment</code>
                            property, and its value <strong><strong>MUST</strong></strong> be a new <em>Update
                                Commitment</em>, the value of which will be revealed for the next Update operation.</li>
                    </ul>
                </li>
                <li>Generate an encoded representation of the following object using the implementation’s <a
                        href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>, herein referred to as the <a
                        href="#update-signed-data-object" id="update-signed-data-object"><em>Update Operation Signed
                            Data Object</em></a>. The object <strong><strong>MUST</strong></strong> be a <a
                        href="https://tools.ietf.org/html/rfc7515">IETF RFC 7515</a> compliant compact JWS object with a
                    signature that validates against a currently active operation key, and contains the following
                    payload values:
                    <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"protected"</span><span class="token operator">:</span> <span class="token punctuation">{</span>...<span class="token punctuation">}</span><span class="token punctuation">,</span>
  <span class="token property">"payload"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
    <span class="token property">"update_key"</span><span class="token operator">:</span> JWK_OBJECT<span class="token punctuation">,</span>
    <span class="token property">"delta_hash"</span><span class="token operator">:</span> DELTA_HASH
  <span class="token punctuation">}</span><span class="token punctuation">,</span>
  <span class="token property">"signature"</span><span class="token operator">:</span> SIGNATURE_STRING
<span class="token punctuation">}</span>
</code></pre>
                    <ul>
                        <li>The JWS <code>payload</code> object <strong><strong>MUST</strong></strong> include a
                            <code>update_key</code> property, and its value <strong><strong>MUST</strong></strong> be
                            the <a href="https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17">JCS
                                canonicalized</a> <a href="https://tools.ietf.org/html/rfc7517">IETF RFC 7517</a>
                            compliant JWK representation matching the previous <em>Update Commitment</em>.</li>
                        <li>The JWS <code>payload</code> object <strong><strong>MUST</strong></strong> contain a
                            <code>delta_hash</code> property, and its value <strong><strong>MUST</strong></strong> be a
                            hash of the decoded <a href="#update-delta-object"><em>Update Operation Delta
                                    Object</em></a>, generated via the <a href="#hashing-process">Hashing Process</a>.
                        </li>
                    </ul>
                </li>
            </ol>
            <h3 id="recover"><a class="toc-anchor" href="#recover">§</a> Recover</h3>
            <p>Use the following process to recover a Sidetree-based DID:</p>
            <ol>
                <li>Retrieve the <em>Recovery Key</em> that matches the previously anchored <em>Recovery
                        Commitment</em>. This value will be used in constructing an <a
                        href="#anchor-file-recovery-entry"><em>Anchor File Recovery Entry</em></a> for the DID being
                    recovered.</li>
                <li>Generate a new <a href="#recovery-key-pair">recovery key pair</a>, which <strong><strong>MUST
                            NOT</strong></strong> be the same key used in any previous operations, via the <a
                        href="#key-algorithm"><code>KEY_ALGORITHM</code></a>, retaining the <em>Next Recovery Public
                        Key</em> for use in generating the next <em>Recovery Commitment</em>, and the private key for
                    use in the next <a href="#recover">Recovery</a> operation.</li>
                <li>Create a <em>Recovery Commitment</em> using the <a href="#hashing-process">Hashing Process</a> to
                    generate a hash value from the <a
                        href="https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17">JCS
                        canonicalized</a> <a href="https://tools.ietf.org/html/rfc7517">IETF RFC 7517</a> JWK
                    representation of the <em>Next Recovery Public Key</em>, and retain the hash value for inclusion in
                    an <a href="#anchor-file">Anchor File</a>.</li>
                <li>Generate a new operation key pair, which <strong><strong>SHOULD NOT</strong></strong> be the same
                    key used in any previous operations, via the <a
                        href="#key-algorithm"><code>KEY_ALGORITHM</code></a>, retaining the <em>Next Update Public
                        Key</em> for use in generating the next <em>Update Commitment</em>, and the private key for use
                    in the next <a href="#update">Update</a> operation.</li>
                <li>Create an <em>Update Commitment</em> using the <a href="#hashing-process">Hashing Process</a> to
                    generate a hash value from the <a
                        href="https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17">JCS
                        canonicalized</a> <a href="https://tools.ietf.org/html/rfc7517">IETF RFC 7517</a> JWK
                    representation of the <em>Next Update Public Key</em>, and retain the hash value for inclusion in
                    the <a href="#recover-delta-object"><em>Recovery Operation Delta Object</em></a>(as described
                    below).</li>
                <li>Generate and retain a <a href="#commitment-value"><code>COMMITMENT_VALUE</code></a>, in adherence
                    with the <a href="#commitment-value-generation">Commitment Value Generation</a> directives, for use
                    in the next Update operation, herein referred to as the <em>Update Reveal Value</em>.</li>
                <li>Generate an <em>Update Commitment</em> using the <a href="#hashing-process">Hashing Process</a>, in
                    adherence with the <a href="#commitment-value-generation">Commitment Value Generation</a>
                    directives, to generate a hash of the <em>Update Reveal Value</em>, and retain the resulting hash
                    value for inclusion in an <a href="#anchor-file">Anchor File</a>.</li>
                <li>Generate an encoded representation of the following object using the implementation’s
                    [<code>DATA_ENCODING_SCHEME</code>], herein referred to as the <a href="#recover-delta-object"
                        id="recover-delta-object"><em>Recovery Operation Delta Object</em></a>, composed as follows:
                    <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"patches"</span><span class="token operator">:</span> <span class="token punctuation">[</span> PATCH_<span class="token number">1</span><span class="token punctuation">,</span> PATCH_<span class="token number">2</span><span class="token punctuation">,</span> ... <span class="token punctuation">]</span><span class="token punctuation">,</span>
  <span class="token property">"update_commitment"</span><span class="token operator">:</span> Update Operation Commitment
<span class="token punctuation">}</span>
</code></pre>
                    <ul>
                        <li>The object <strong><strong>MUST</strong></strong> contain a <code>patches</code> property,
                            and its value <strong><strong>MUST</strong></strong> be an array of <a
                                href="#did-state-patches">DID State Patches</a>.</li>
                        <li>The object <strong><strong>MUST</strong></strong> contain a <code>update_commitment</code>
                            property, and its value <strong><strong>MUST</strong></strong> be the <em>Update
                                Commitment</em>, as described above.</li>
                    </ul>
                </li>
                <li>Generate an encoded representation of the following object using the implementation’s <a
                        href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>, herein referred to as the <a
                        href="#recovery-signed-data-object" id="recovery-signed-data-object"><em>Recovery Operation
                            Signed Data Object</em></a>. The object <strong><strong>MUST</strong></strong> be a <a
                        href="https://tools.ietf.org/html/rfc7515">IETF RFC 7515</a> compliant compact JWS object with a
                    signature that validates against the currently active recovery key, and contains the following
                    <code>payload</code> values:
                    <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"protected"</span><span class="token operator">:</span> <span class="token punctuation">{</span>...<span class="token punctuation">}</span><span class="token punctuation">,</span>
  <span class="token property">"payload"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
    <span class="token property">"recovery_commitment"</span><span class="token operator">:</span> Recovery Commitment<span class="token punctuation">,</span>
    <span class="token property">"recovery_key"</span><span class="token operator">:</span> JWK_OBJECT<span class="token punctuation">,</span>
    <span class="token property">"delta_hash"</span><span class="token operator">:</span> DELTA_HASH
  <span class="token punctuation">}</span><span class="token punctuation">,</span>
  <span class="token property">"signature"</span><span class="token operator">:</span> SIGNATURE_STRING
<span class="token punctuation">}</span>
</code></pre>
                    <ul>
                        <li>The JWS <code>payload</code> object <strong><strong>MUST</strong></strong> contain a
                            <code>recovery_commitment</code> property, and its value
                            <strong><strong>MUST</strong></strong> be the next <a
                                href="#recovery-commitment"><em>Recovery Commitment</em></a>, as described above.</li>
                        <li>The JWS <code>payload</code> object <strong><strong>MUST</strong></strong> include a
                            <code>recovery_key</code> property, and its value <strong><strong>MUST</strong></strong> be
                            the <a href="https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17">JCS
                                canonicalized</a> <a href="https://tools.ietf.org/html/rfc7517">IETF RFC 7517</a>
                            compliant JWK representation matching the previous <em>Recovery Commitment</em>.</li>
                        <li>The JWS <code>payload</code> object <strong><strong>MUST</strong></strong> contain a
                            <code>delta_hash</code> property, and its value <strong><strong>MUST</strong></strong> be a
                            hash of the decoded <a href="#recover-delta-object"><em>Recovery Operation Delta
                                    Object</em></a>, generated via the <a href="#hashing-process">Hashing Process</a>.
                        </li>
                    </ul>
                </li>
            </ol>
            <h3 id="deactivate"><a class="toc-anchor" href="#deactivate">§</a> Deactivate</h3>
            <p>The following process must be used to deactivate a Sidetree-based DID:</p>
            <ol>
                <li>Retrieve the <em>Recovery Reveal Value</em> that matches the previously anchored <em>Recovery
                        Commitment</em>.</li>
                <li>Generate an encoded representation of the following object using the implementation’s <a
                        href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>, herein referred to as the <a
                        href="#deactivate-signed-data-object" id="deactivate-signed-data-object"><em>Deactivate
                            Operation Signed Data Object</em></a>. The object <strong><strong>MUST</strong></strong> be
                    a <a href="https://tools.ietf.org/html/rfc7515">IETF RFC 7515</a> compliant compact JWS object with
                    a signature that validates against the currently active recovery key, and contains the following
                    payload values:
                    <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span> <span class="token comment">// Base64URL encoded, compact JWS</span>
  <span class="token property">"protected"</span><span class="token operator">:</span> <span class="token punctuation">{</span>...<span class="token punctuation">}</span><span class="token punctuation">,</span>
  <span class="token property">"payload"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
    <span class="token property">"did_suffix"</span><span class="token operator">:</span> SUFFIX_STRING<span class="token punctuation">,</span>
    <span class="token property">"recovery_key"</span><span class="token operator">:</span> JWK_OBJECT
  <span class="token punctuation">}</span><span class="token punctuation">,</span>
  <span class="token property">"signature"</span><span class="token operator">:</span> SIGNATURE_STRING
<span class="token punctuation">}</span>
</code></pre>
                    <ul>
                        <li>The JWS <code>payload</code> object <strong><strong>MUST</strong></strong> contain a
                            <code>did_suffix</code> property, and its value <strong><strong>MUST</strong></strong> be
                            the <a href="#did-suffix">DID Suffix</a> of the DID the operation pertains to.</li>
                        <li>The JWS <code>payload</code> object <strong><strong>MUST</strong></strong> contain a
                            <code>recovery_key</code> property, and its value <strong><strong>MUST</strong></strong>
                            match the last <em>Recovery Commitment</em>.</li>
                    </ul>
                </li>
            </ol>
            <h2 id="did-state-patches"><a class="toc-anchor" href="#did-state-patches">§</a> DID State Patches</h2>
            <p>Sidetree defines a general format for patching DID State, called <em>Patch Actions</em>, for describing
                mutations of a DID’s metadata state. Sidetree further defines a standard set of <em>Patch Actions</em>
                (below) implementers MAY use to facilitate patching within their implementations. Support of the
                standard set of <em>Patch Actions</em> defined herein IS NOT required, but implementers
                <strong><strong>MUST</strong></strong> use the <em>Patch Action</em> format for defining patch
                mechanisms within their implementation. The general <em>Patch Action</em> format is defined as follows:
            </p>
            <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"action"</span><span class="token operator">:</span> <span class="token string">"add-public-keys"</span><span class="token punctuation">,</span>
  ...
<span class="token punctuation">}</span>

<span class="token punctuation">{</span>
  <span class="token property">"action"</span><span class="token operator">:</span> <span class="token string">"-custom-action"</span><span class="token punctuation">,</span>
  ...
<span class="token punctuation">}</span>
</code></pre>
            <ol>
                <li><em>Patch Actions</em> <strong><strong>MUST</strong></strong> be represented as JSON objects.</li>
                <li><em>Patch Action</em> objects <strong><strong>MUST</strong></strong> include an <code>action</code>
                    property, and its value <strong><strong>SHOULD</strong></strong> be one of the standard <em>Patch
                        Action</em> types listed in below, or, if the implementer chooses to create a custom <em>Patch
                        Action</em>, a kebab-case string (dash-delimited lowercase words) with a leading dash, to
                    indicate a custom <em>Patch Action</em>, for example: <code>-custom-action</code>.
                    <ul>
                        <li><code>add-public-keys</code></li>
                        <li><code>remove-public-keys</code></li>
                        <li><code>add-service-endpoints</code></li>
                        <li><code>remove-service-endpoints</code></li>
                        <li><code>ietf-json-patch</code></li>
                    </ul>
                </li>
            </ol>
            <h3 id="standard-patch-actions"><a class="toc-anchor" href="#standard-patch-actions">§</a> Standard Patch
                Actions</h3>
            <p>The following set of standard <em>Patch Actions</em> are specified to help align on a common set of
                <em>Patch Actions</em> that provide a predictable usage patter across Sidetree-based DID Method
                implementations.</p>
            <h4 id="add-public-keys"><a class="toc-anchor" href="#add-public-keys">§</a> <code>add-public-keys</code>
            </h4>
            <div id="example-9" class="notice example"><a class="notice-link" href="#example-9">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"action"</span><span class="token operator">:</span> <span class="token string">"add-public-keys"</span><span class="token punctuation">,</span>
  <span class="token property">"public_keys"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
    <span class="token punctuation">{</span>
      <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"key1"</span><span class="token punctuation">,</span>
      <span class="token property">"purpose"</span><span class="token operator">:</span> <span class="token punctuation">[</span><span class="token string">"auth"</span><span class="token punctuation">]</span><span class="token punctuation">,</span>
      <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"EcdsaSecp256k1VerificationKey2019"</span><span class="token punctuation">,</span>
      <span class="token property">"jwk"</span><span class="token operator">:</span> <span class="token punctuation">{</span>...<span class="token punctuation">}</span>
    <span class="token punctuation">}</span>
  <span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <p>The <code>add-public-keys</code> <em>Patch Action</em> describes the addition of cryptographic keys
                associated with a given DID. For any part of an <code>add-public-keys</code> <em>Patch Action</em> to be
                applied to the DID’s state, all specified conditions <strong><strong>MUST</strong></strong> be met for
                all properties and values, else the patch <strong><strong>MUST</strong></strong> be discarded in its
                entirety. To construct an <code>add-public-keys</code> patch, compose an object as follows:</p>
            <ol>
                <li>The object <strong><strong>MUST</strong></strong> include an <code>action</code> property, and its
                    value <strong><strong>MUST</strong></strong> be <code>add-public-keys</code>.</li>
                <li>The object <strong><strong>MUST</strong></strong> include a <code>public_keys</code> property, and
                    its value <strong><strong>MUST</strong></strong> be an array.</li>
                <li>Each key being added <strong><strong>MUST</strong></strong> be represented by an entry in the
                    <code>public_keys</code> array, and each entry must be an object composed as follows:
                    <ol>
                        <li>The object <strong><strong>MUST</strong></strong> include an <code>id</code> property, and
                            its value <strong><strong>MUST</strong></strong> be a string with no more than fifty (50)
                            ASCII encoded characters. If the value is not of the correct type or exceeds the specified
                            length, the entire <em>Patch Action</em> <strong><strong>MUST</strong></strong> be
                            discarded, without any of it being used to modify the DID’s state.</li>
                        <li>The object <strong><strong>MUST</strong></strong> include a type property, and its value
                            <strong><strong>SHOULD</strong></strong> be the identifier type string of a registered <a
                                href="https://w3c-ccg.github.io/ld-cryptosuite-registry/">Cryptographic Suite</a> that
                            supports JWK representations - for example:
                            <ul>
                                <li><code>EcdsaSecp256k1VerificationKey2019</code></li>
                                <li><code>JwsVerificationKey2020</code></li>
                            </ul>
                        </li>
                        <li>The object <strong><strong>MUST</strong></strong> include a <code>jwk</code> property, and
                            its value <strong><strong>MUST</strong></strong> be a public key expressed as a <a
                                href="https://tools.ietf.org/html/rfc7517">IETF RFC 7517</a> compliant JWK
                            representation for a <a href="#key-algorithm"><code>KEY_ALGORITHM</code></a> supported by
                            the implementation. If the value is not a compliant JWK representation, the entire <em>Patch
                                Action</em> <strong><strong>MUST</strong></strong> be discarded, without any of it being
                            used to modify the DID’s state.</li>
                        <li>The object <strong><strong>MUST</strong></strong> include a <code>purpose</code> property,
                            and its value <strong><strong>MUST</strong></strong> be an array that includes one or more
                            of the strings listed below. If the value is not of the correct type or contains any string
                            not listed below, the entire <em>Patch Action</em> <strong><strong>MUST</strong></strong> be
                            discarded, without any of it being used to modify the DID’s state.
                            <ul>
                                <li><strong><code>general</code></strong>: the key
                                    <strong><strong>MUST</strong></strong> be included in the <code>public_keys</code>
                                    section of the resolved <em>DID Document</em>.</li>
                                <li><strong><code>auth</code></strong>: the key <strong><strong>MUST</strong></strong>
                                    be included in the <code>authentication</code> section of the resolved <em>DID
                                        Document</em>, as follows:
                                    <ul>
                                        <li>If the <code>general</code> purpose value IS NOT present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be included directly in the
                                            <code>authentication</code> section of the resolved <em>DID Document</em>.
                                        </li>
                                        <li>If the <code>general</code> purpose value IS present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be directly included in the
                                            <code>public_keys</code> section of the resolved <em>DID Document</em>, and
                                            <strong><strong>MUST</strong></strong> be included by <a
                                                href="https://w3c.github.io/did-core/#relative-did-urls">relative DID
                                                URL reference</a> in the <code>authentication</code> section.</li>
                                    </ul>
                                </li>
                                <li><strong><code>agreement</code></strong>: the key
                                    <strong><strong>MUST</strong></strong> be included in the <code>keyAgreement</code>
                                    section of the resolved <em>DID Document</em>, as follows:
                                    <ul>
                                        <li>If the <code>general</code> purpose value IS NOT present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be included directly in the
                                            <code>keyAgreement</code> section of the resolved <em>DID Document</em>.
                                        </li>
                                        <li>If the <code>general</code> purpose value IS present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be directly included in the
                                            <code>public_keys</code> section of the resolved <em>DID Document</em>, and
                                            <strong><strong>MUST</strong></strong> be included by <a
                                                href="https://w3c.github.io/did-core/#relative-did-urls">relative DID
                                                URL reference</a> in the <code>keyAgreement</code> section.</li>
                                    </ul>
                                </li>
                                <li><strong><code>assertion</code></strong>: the key
                                    <strong><strong>MUST</strong></strong> be included in the
                                    <code>assertionMethod</code> section of the resolved <em>DID Document</em>, as
                                    follows:
                                    <ul>
                                        <li>If the <code>general</code> purpose value IS NOT present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be included directly in the
                                            <code>assertionMethod</code> section of the resolved <em>DID Document</em>.
                                        </li>
                                        <li>If the <code>general</code> purpose value IS present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be directly included in the
                                            <code>public_keys</code> section of the resolved <em>DID Document</em>, and
                                            <strong><strong>MUST</strong></strong> be included by <a
                                                href="https://w3c.github.io/did-core/#relative-did-urls">relative DID
                                                URL reference</a> in the <code>assertionMethod</code> section.</li>
                                    </ul>
                                </li>
                                <li><strong><code>delegation</code></strong>: the key
                                    <strong><strong>MUST</strong></strong> be included in the
                                    <code>capabilityDelegation</code> section of the resolved <em>DID Document</em>, as
                                    follows:
                                    <ul>
                                        <li>If the <code>general</code> purpose value IS NOT present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be included directly in the
                                            <code>capabilityDelegation</code> section of the resolved <em>DID
                                                Document</em>.</li>
                                        <li>If the <code>general</code> purpose value IS present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be directly included in the
                                            <code>public_keys</code> section of the resolved <em>DID Document</em>, and
                                            <strong><strong>MUST</strong></strong> be included by <a
                                                href="https://w3c.github.io/did-core/#relative-did-urls">relative DID
                                                URL reference</a> in the <code>capabilityDelegation</code> section.</li>
                                    </ul>
                                </li>
                                <li><strong><code>invocation</code></strong>: the key
                                    <strong><strong>MUST</strong></strong> be included in the
                                    <code>capabilityInvocation</code> section of the resolved <em>DID Document</em>, as
                                    follows:
                                    <ul>
                                        <li>If the <code>general</code> purpose value IS NOT present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be included directly in the
                                            <code>capabilityInvocation</code> section of the resolved <em>DID
                                                Document</em>.</li>
                                        <li>If the <code>general</code> purpose value IS present in the
                                            <code>purpose</code> array, the key descriptor object
                                            <strong><strong>MUST</strong></strong> be directly included in the
                                            <code>public_keys</code> section of the resolved <em>DID Document</em>, and
                                            <strong><strong>MUST</strong></strong> be included by <a
                                                href="https://w3c.github.io/did-core/#relative-did-urls">relative DID
                                                URL reference</a> in the <code>capabilityInvocation</code> section.</li>
                                    </ul>
                                </li>
                            </ul>
                        </li>
                    </ol>
                </li>
            </ol>
            <h4 id="remove-public-keys"><a class="toc-anchor" href="#remove-public-keys">§</a>
                <code>remove-public-keys</code></h4>
            <div id="example-10" class="notice example"><a class="notice-link" href="#example-10">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"action"</span><span class="token operator">:</span> <span class="token string">"remove-public-keys"</span><span class="token punctuation">,</span>
  <span class="token property">"public_keys"</span><span class="token operator">:</span> <span class="token punctuation">[</span><span class="token string">"key1"</span><span class="token punctuation">,</span> <span class="token string">"key2"</span><span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <p>The <code>remove-public-keys</code> <em>Patch Action</em> describes the removal of cryptographic keys
                associated with a given DID. For any part of an <code>remove-public-keys</code> <em>Patch Action</em> to
                be applied to the DID’s state, all specified conditions <strong><strong>MUST</strong></strong> be met
                for all properties and values, else the patch <strong><strong>MUST</strong></strong> be discarded in its
                entirety. To construct a <code>remove-public-keys</code> <em>Patch Action</em>, compose an object as
                follows:</p>
            <ol>
                <li>The object <strong><strong>MUST</strong></strong> include an <code>action</code> property, and its
                    value <strong><strong>MUST</strong></strong> be <code>remove-public-keys</code>.</li>
                <li>The object <strong><strong>MUST</strong></strong> include a <code>public_keys</code> property, and
                    its value <strong><strong>MUST</strong></strong> be an array of key IDs that correspond with keys
                    presently associated with the DID that are to be removed. If the value is not of the correct type or
                    includes a string value that is not associated with a key in the document, the entire <em>Patch
                        Action</em> <strong><strong>MUST</strong></strong> be discarded, without any of it being used to
                    modify the DID’s state.</li>
            </ol>
            <h4 id="add-service-endpoints"><a class="toc-anchor" href="#add-service-endpoints">§</a>
                <code>add-service-endpoints</code></h4>
            <div id="example-11" class="notice example"><a class="notice-link" href="#example-11">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"action"</span><span class="token operator">:</span> <span class="token string">"add-service-endpoints"</span><span class="token punctuation">,</span>
  <span class="token property">"service_endpoints"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
    <span class="token punctuation">{</span>
      <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"sds1"</span><span class="token punctuation">,</span>
      <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"SecureDataStore"</span><span class="token punctuation">,</span>
      <span class="token property">"endpoint"</span><span class="token operator">:</span> <span class="token string">"http://hub.my-personal-server.com"</span>
    <span class="token punctuation">}</span><span class="token punctuation">,</span>
    <span class="token punctuation">{</span>
      <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"sds2"</span><span class="token punctuation">,</span>
      <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"SecureDataStore"</span><span class="token punctuation">,</span>
      <span class="token property">"endpoint"</span><span class="token operator">:</span> <span class="token string">"http://some-cloud.com/hub"</span>
    <span class="token punctuation">}</span>
  <span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <p>The <code>add-service-endpoints</code> <em>Patch Action</em> describes the addition of <a
                    href="https://w3c.github.io/did-core/#service-endpoints">Service Endpoints</a> to a DID’s state. For
                any part of an <code>add-service-endpoints</code> <em>Patch Action</em> to be applied to the DID’s
                state, all specified conditions <strong><strong>MUST</strong></strong> be met for all properties and
                values, else the patch <strong><strong>MUST</strong></strong> be discarded in its entirety. To construct
                an <code>add-service-endpoints</code> patch, compose an object as follows:</p>
            <ol>
                <li>The object <strong><strong>MUST</strong></strong> include an <code>action</code> property, and its
                    value <strong><strong>MUST</strong></strong> be <code>add-service-endpoints</code>.</li>
                <li>The object <strong><strong>MUST</strong></strong> include a <code>service_endpoints</code> property,
                    and its value <strong><strong>MUST</strong></strong> be an array. If the value is not of the correct
                    type, the entire <em>Patch Action</em> <strong><strong>MUST</strong></strong> be discarded, without
                    any of it being used to modify the DID’s state.</li>
                <li>Each service being added <strong><strong>MUST</strong></strong> be represented by an entry in the
                    <code>service_endpoints</code> array, and each entry must be an object composed as follows:
                    <ol>
                        <li>The object <strong><strong>MUST</strong></strong> include an <code>id</code> property, and
                            its value <strong><strong>MUST</strong></strong> be a string with a length of no more than
                            fifty (50) ASCII encoded characters. If the value is not of the correct type or exceeds the
                            specified length, the entire <em>Patch Action</em> <strong><strong>MUST</strong></strong> be
                            discarded, without any of it being used to modify the DID’s state.</li>
                        <li>The object <strong><strong>MUST</strong></strong> include a <code>type</code> property, and
                            its value <strong><strong>MUST</strong></strong> be a string with a length of no more than
                            thirty (30) ASCII encoded characters. If the value is not a string or exceeds the specified
                            length, the entire <em>Patch Action</em> <strong><strong>MUST</strong></strong> be
                            discarded, without any of it being used to modify the DID’s state.</li>
                        <li>The object <strong><strong>MUST</strong></strong> include a <code>endpoint</code> property,
                            and its value <strong><strong>MUST</strong></strong> be a valid URI string (including a
                            scheme segment: i.e. http://, git://) with a length of no more than one hundred (100) ASCII
                            encoded characters. If the value is not a valid URI or exceeds the specified length, the
                            entire <em>Patch Action</em> <strong><strong>MUST</strong></strong> be discarded, without
                            any of it being used to modify the DID’s state.</li>
                    </ol>
                </li>
            </ol>
            <h4 id="remove-service-endpoints"><a class="toc-anchor" href="#remove-service-endpoints">§</a>
                <code>remove-service-endpoints</code></h4>
            <div id="example-12" class="notice example"><a class="notice-link" href="#example-12">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"action"</span><span class="token operator">:</span> <span class="token string">"remove-service-endpoints"</span><span class="token punctuation">,</span>
  <span class="token property">"ids"</span><span class="token operator">:</span> <span class="token punctuation">[</span><span class="token string">"sds1"</span><span class="token punctuation">,</span> <span class="token string">"sds2"</span><span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <p>The <code>remove-service-endpoints</code> <em>Patch Action</em> describes the removal of cryptographic
                keys associated with a given DID. For any part of an <code>remove-service-endpoints</code> <em>Patch
                    Action</em> to be applied to the DID’s state, all specified conditions
                <strong><strong>MUST</strong></strong> be met for all properties and values, else the patch
                <strong><strong>MUST</strong></strong> be discarded in its entirety. To construct a
                <code>remove-service-endpoints</code> <em>Patch Action</em>, compose an object as follows:</p>
            <ol>
                <li>The object <strong><strong>MUST</strong></strong> include an <code>action</code> property, and its
                    value <strong><strong>MUST</strong></strong> be <code>remove-service-endpoints</code>.</li>
                <li>The object <strong><strong>MUST</strong></strong> include a <code>ids</code> property, and its value
                    <strong><strong>MUST</strong></strong> be an array of Service Endpoint IDs that correspond with
                    Service Endpoints presently associated with the DID that are to be removed.</li>
            </ol>
            <h4 id="replace"><a class="toc-anchor" href="#replace">§</a> <code>replace</code></h4>
            <div id="example-13" class="notice example"><a class="notice-link" href="#example-13">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"action"</span><span class="token operator">:</span> <span class="token string">"replace"</span><span class="token punctuation">,</span>
  <span class="token property">"document"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
    <span class="token property">"public_keys"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
      <span class="token punctuation">{</span>
        <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"key2"</span><span class="token punctuation">,</span>
        <span class="token property">"purpose"</span><span class="token operator">:</span> <span class="token punctuation">[</span><span class="token string">"auth"</span><span class="token punctuation">]</span><span class="token punctuation">,</span>
        <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"EcdsaSecp256k1VerificationKey2019"</span><span class="token punctuation">,</span>
        <span class="token property">"jwk"</span><span class="token operator">:</span> <span class="token punctuation">{</span>...<span class="token punctuation">}</span>
      <span class="token punctuation">}</span>
    <span class="token punctuation">]</span><span class="token punctuation">,</span>
    <span class="token property">"service_endpoints"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
      <span class="token punctuation">{</span>
        <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"sds3"</span><span class="token punctuation">,</span>
        <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"SecureDataStore"</span><span class="token punctuation">,</span>
        <span class="token property">"endpoint"</span><span class="token operator">:</span> <span class="token string">"http://hub.my-personal-server.com"</span>
      <span class="token punctuation">}</span>
    <span class="token punctuation">]</span>
  <span class="token punctuation">}</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <p>The <code>replace</code> <em>Patch Action</em> acts as a total state reset that replaces a DID’s current
                PKI metadata state with the state provided. The <code>replace</code> <em>Patch Action</em> enables the
                declaration of public keys and service endpoints using the same schema formats as the
                <code>add-public-keys</code> and <code>add-service-endpoints</code> <em>Patch Actions</em>. To construct
                a <code>replace</code> patch, compose an object as follows:</p>
            <ol>
                <li>The object <strong><strong>MUST</strong></strong> include an <code>action</code> property, and its
                    value <strong><strong>MUST</strong></strong> be <code>replace</code>.</li>
                <li>The object <strong><strong>MUST</strong></strong> include a <code>document</code> property, and its
                    value <strong><strong>MUST</strong></strong> be an object, which may contain the following
                    properties:
                    <ul>
                        <li>The object <strong><strong>MAY</strong></strong> include a <code>public_keys</code>
                            property, and if present, its value <strong><strong>MUST</strong></strong> be an array of
                            public key entries that follow the same schema and requirements as the public key entries
                            from the <a href="#add-public-keys"><code>add-public-keys</code></a> <em>Patch Action</em>
                        </li>
                        <li>The object <strong><strong>MAY</strong></strong> include a <code>service_endpoints</code>
                            property, and if present, its value <strong><strong>MUST</strong></strong> be an array of
                            service endpoint entries that follow the same schema and requirements as the service
                            endpoint entries from the <a
                                href="#add-service-endpoints"><code>add-service-endpoints</code></a> <em>Patch
                                Action</em>.</li>
                    </ul>
                </li>
            </ol>
            <h4 id="ietf-json-patch"><a class="toc-anchor" href="#ietf-json-patch">§</a> <code>ietf-json-patch</code>
            </h4>
            <p>The <code>ietf-json-patch</code> Patch Action describes a mechanism for modifying a DID’s state using <a
                    href="https://tools.ietf.org/html/rfc6902">IETF JSON Patch</a>. To construct a
                <code>ietf-json-patch</code> <em>Patch Action</em>, compose an object as follows:</p>
            <ol>
                <li>The object <strong><strong>MUST</strong></strong> include an <code>action</code> property, and its
                    value <strong><strong>MUST</strong></strong> be <code>ietf-json-patch</code>.</li>
                <li>The object <strong><strong>MUST</strong></strong> include a <code>patches</code> property, and its
                    value <strong><strong>MUST</strong></strong> be an array of <a
                        href="https://tools.ietf.org/html/rfc6902">IETF JSON Patch</a> operation objects.</li>
            </ol>
            <p>If <code>ietf-json-patch</code> is used to add or remove from a proof purpose collection, such as
                <code>operations</code>, <code>recovery</code> or <code>assertionMethod</code>, per the DID Core spec,
                each collection element MUST have a unique <code>id</code> property, or be a unique string identifier.
            </p>
            <p>See <a href="https://identity.foundation/sidetree/spec/#operation-verification">Operation
                    Verification</a> for more details on how operations are verified.</p>
            <div id="1" class="notice example"><a class="notice-link" href="#1">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"action"</span><span class="token operator">:</span> <span class="token string">"ietf-json-patch"</span><span class="token punctuation">,</span>
  <span class="token property">"patches"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
    <span class="token punctuation">{</span> <span class="token property">"op"</span><span class="token operator">:</span> <span class="token string">"add"</span><span class="token punctuation">,</span> ... <span class="token punctuation">}</span><span class="token punctuation">,</span>
    <span class="token punctuation">{</span> <span class="token property">"op"</span><span class="token operator">:</span> <span class="token string">"remove"</span><span class="token punctuation">,</span> ... <span class="token punctuation">}</span><span class="token punctuation">,</span>
    <span class="token punctuation">{</span> <span class="token property">"op"</span><span class="token operator">:</span> <span class="token string">"replace"</span><span class="token punctuation">,</span> ... <span class="token punctuation">}</span><span class="token punctuation">,</span>
    <span class="token punctuation">{</span> <span class="token property">"op"</span><span class="token operator">:</span> <span class="token string">"move"</span><span class="token punctuation">,</span> ... <span class="token punctuation">}</span><span class="token punctuation">,</span>
    <span class="token punctuation">{</span> <span class="token property">"op"</span><span class="token operator">:</span> <span class="token string">"copy"</span><span class="token punctuation">,</span> ... <span class="token punctuation">}</span>
  <span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <div id="2" class="notice example"><a class="notice-link" href="#2">EXAMPLE</a>
                <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"action"</span><span class="token operator">:</span> <span class="token string">"ietf-json-patch"</span><span class="token punctuation">,</span>
  <span class="token property">"patches"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
    <span class="token punctuation">{</span>
      <span class="token property">"op"</span><span class="token operator">:</span> <span class="token string">"replace"</span><span class="token punctuation">,</span>
      <span class="token property">"path"</span><span class="token operator">:</span> <span class="token string">"/service"</span><span class="token punctuation">,</span>
      <span class="token property">"value"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
          <span class="token punctuation">{</span>
              <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"did:example:123#edv"</span><span class="token punctuation">,</span>
              <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"EncryptedDataVault"</span><span class="token punctuation">,</span>
              <span class="token property">"serviceEndpoint"</span><span class="token operator">:</span> <span class="token string">"https://edv.example.com/"</span><span class="token punctuation">,</span>
          <span class="token punctuation">}</span><span class="token punctuation">,</span>
      <span class="token punctuation">]</span><span class="token punctuation">,</span>
      <span class="token punctuation">}</span>
  <span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            </div>
            <div id="warning-7" class="notice warning"><a class="notice-link" href="#warning-7">WARNING</a>
                <p>Without careful validation, use of <code>ietf-json-patch</code> may result in unrecoverable states,
                    similar to “Deactivated”.</p>
            </div>
            <div id="warning-8" class="notice warning"><a class="notice-link" href="#warning-8">WARNING</a>
                <p>Use of <code>ietf-json-patch</code> may harm an implmentation’s ability to perform validation on
                    operations at ingestion time, which could impact performance negatively.</p>
            </div>
            <h2 id="transaction-operation-processing"><a class="toc-anchor"
                    href="#transaction-operation-processing">§</a> Transaction &amp; Operation Processing</h2>
            <h3 id="transaction-anchoring"><a class="toc-anchor" href="#transaction-anchoring">§</a> Transaction
                Anchoring</h3>
            <p>Once an Anchor File, Map File, and associated Chunk Files have been assembled for a given set of
                operations, a reference to the <a href="#anchor-file">Anchor File</a> must be embedded within the target
                ledger to enter the set of operations into the Sidetree implementation’s global state. The following
                process:</p>
            <ol>
                <li>Generate a transaction for the underlying ledger</li>
                <li>Generate and include the following value, herein referred to as the <a href="#anchor-string"
                        id="anchor-string"><em>Anchor String</em></a>, within the transaction:
                    <ol>
                        <li>Generate a numerical string (<code>'732'</code>) that represents the total number of
                            operations present in the <a href="#anchor-file">Anchor File</a> and <a href="#map-file">Map
                                File</a>, herein referred to as the <em>Operation Count</em>.</li>
                        <li>Using the <a href="#cas-uri-algorithm"><code>CAS_URI_ALGORITHM</code></a>, generate a CID
                            for the Anchor File, herein referred to as the <em>Anchor File CAS URI</em>.</li>
                        <li>Join the <em>Operation Count</em> and <em>Anchor File CAS URI</em> with a <code>.</code> as
                            follows:
                            <pre class="language-js"><code class="language-js"><span class="token string">"10000"</span> <span class="token operator">+</span> <span class="token string">"."</span> <span class="token operator">+</span> <span class="token string">"QmWd5PH6vyRH5kMdzZRPBnf952dbR4av3Bd7B2wBqMaAcf"</span>
</code></pre>
                        </li>
                        <li>Embed the <em>Anchor String</em> in the transaction such that it can be located and parsed
                            by any party that traverses the history of the target ledger.</li>
                    </ol>
                </li>
                <li>If the implementation implements a <a href="#proof-of-fee">per-op fee</a>, ensure the transaction
                    includes the fee amount required for the number of operations being anchored.</li>
                <li>Encode the transaction with any other data or values required for inclusion by the target ledger,
                    and broadcast it.</li>
            </ol>
            <h3 id="cas-file-propagation"><a class="toc-anchor" href="#cas-file-propagation">§</a> CAS File Propagation
            </h3>
            <p>To ensure other nodes of the implementation can retrieve the <a href="#file-structures">operation
                    files</a> required to ingest the included operations and update the states of the DIDs it contains,
                the implementer must ensure that the files associated with a given set of operations being anchored are
                available to peers seeking to request and replicate them across the CAS storage layer. Use the following
                procedure for propagating transaction-anchored CAS files:</p>
            <ol>
                <li>If the underlying ledger is subject to an anchoring inclusion delay (e.g. the interval between
                    blocks in a blockchain), implementers <strong><strong>SHOULD</strong></strong> wait until they
                    receive a confirmation of inclusion (whatever that means for the target ledger) before
                    exposing/propagating the <a href="#file-structures">operation files</a> across the CAS network.
                    (more about the reason for this in the note below)</li>
                <li>After confirmation is received, implementers <strong><strong>SHOULD</strong></strong> use the most
                    effective means of proactive propagation the <a href="#cas-protocol"><code>CAS_PROTOCOL</code></a>
                    supports.</li>
                <li>A Sidetree-based implementation node that anchors operations should not assume other nodes on the
                    CAS network will indefinitely retain and propagate the <a href="#file-structures">files</a> for a
                    given set of operations they anchor. A node <strong><strong>SHOULD</strong></strong> retain and
                    propagate any files related to the operations it anchors.</li>
            </ol>
            <div id="cas-propagation-delay" class="notice note"><a class="notice-link"
                    href="#cas-propagation-delay">NOTE</a>
                <p>Most ledgers feature some delay between the broadcast of a transaction and the recorded inclusion of
                    the transaction in the ledger’s history. Because operation data included in the CAS files contains
                    revealed commitment values for operations, propagating those files before confirmation of
                    transaction inclusion exposes revealed commitment values to external entities who may download them
                    prior to inclusion in the ledger. This means an attacker who learns of the revealed commitment value
                    can craft invalid transactions that could be included before the legitimate operation the user is
                    attempting to anchor. While this has no affect on proof-of-control security for a DID, an observing
                    node would have to check the signatures of fraudulent transactions before the legitimate transaction
                    is found, which could result in slower resolution processing for the target DID.</p>
            </div>
            <h3 id="transaction-processing"><a class="toc-anchor" href="#transaction-processing">§</a> Transaction
                Processing</h3>
            <p>Regardless of the ledger system an implementer chooses, the implementer
                <strong><strong>MUST</strong></strong> be able to sequence Sidetree-specific transactions within it in a
                deterministic order, such that any observer can derive the same order if the same logic is applied. The
                implementer MUST, either at the native transaction level or by some means of logical evaluation, assign
                Sidetree-specific transactions a <a href="#transaction-number"><em>Transaction Number</em></a>. <a
                    href="#transaction-number"><em>Transaction Numbers</em></a> <strong><strong>MUST</strong></strong>
                be assigned to all Sidetree-specific transactions present in the underlying ledger after <a
                    href="#genesis-time"><code>GENESIS_TIME</code></a>, regardless of whether or not they are valid.</p>
            <ol>
                <li>An implementer <strong><strong>MUST</strong></strong> develop implementation-specific logic that
                    enables deterministic ordering and iteration of all protocol-related transactions in the underlying
                    ledger, such that all operators of the implementation process them in the same order.</li>
                <li>Starting at <a href="#genesis-time"><code>GENESIS_TIME</code></a>, begin iterating transactions
                    using the implementation-specific logic.</li>
                <li>For each transaction found during iteration that is determined to be a protocol-related transaction,
                    process the transaction as follows:
                    <ol>
                        <li>Assign the transaction a <em>Transaction Number</em>.</li>
                        <li>If the implementation supports enforcement value locking, and the transaction is encoded in
                            accordance with the implementation’s value locking format, skip the remaining steps and
                            process the transaction as described in the <a href="#proof-of-fee">Proof of Fee</a> section
                            on <a href="#value-locking">Value Locking</a>.</li>
                        <li>The <a href="#anchor-string"><em>Anchor String</em></a>
                            <strong><strong>MUST</strong></strong> be formatted correctly - if it IS NOT, discard the
                            transaction and continue iteration.</li>
                        <li>If the implementation DOES NOT support enforcement of a <a
                                href="#proof-of-fee">per-operation fee</a>, skip this step. If enforcement of a <a
                                href="#proof-of-fee">per-operation fee</a> is supported, ensure the transaction fee
                            meets the <a href="#proof-of-fee">per-operation fee</a> requirements for inclusion - if it
                            DOES NOT, discard the transaction and continue iteration.</li>
                        <li>If the implementation DOES NOT support enforcement of <a href="#value-locking">Value
                                Locking</a>, skip this step. If enforcement of <a href="#value-locking">Value
                                Locking</a> is supported, ensure the transaction’s fee meets the <a
                                href="#value-locking">Value Locking</a> requirements for inclusion - if it does not,
                            discard the transaction and continue iteration.</li>
                        <li>Parse the <a href="#anchor-string"><em>Anchor String</em></a> to derive the <em>Operation
                                Count</em> and <em>Anchor File CAS URI</em>.</li>
                        <li>Use the <a href="#cas-protocol"><code>CAS_PROTOCOL</code></a> to fetch the <a
                                href="#anchor-file">Anchor File</a> using the <em>Anchor File CAS URI</em>. If the file
                            cannot be located, retain a reference that signifies the need to retry fetch of the file. If
                            the file successfully retrieved, proceed to the next section on how to <a
                                href="#anchor-file-processing">process an Anchor File</a></li>
                    </ol>
                </li>
            </ol>
            <h3 id="anchor-file-processing"><a class="toc-anchor" href="#anchor-file-processing">§</a> Anchor File
                Processing</h3>
            <p>The follow sequence of rules and processing steps must be followed to correctly process an <a
                    href="#anchor-file">Anchor File</a>:</p>
            <ol>
                <li>
                    <p>The <a href="#anchor-file">Anchor File</a> <strong><strong>MUST NOT</strong></strong> exceed the
                        <a href="#max-anchor-file-size"><code>MAX_ANCHOR_FILE_SIZE</code></a> - if it does, cease
                        processing, discard the file data, and retain a reference that the file is to be ignored.</p>
                </li>
                <li>
                    <p>The <a href="#anchor-file">Anchor File</a> <strong><strong>MUST</strong></strong> validate
                        against the protocol-defined <a href="#anchor-file">Anchor File</a> schema and construction
                        rules - if it DOES NOT, cease processing, discard the file data, and retain a reference that the
                        file is to be ignored.</p>
                    <ul>
                        <li>While this rule is articulated in the <a href="#anchor-file">Anchor File</a> section of the
                            specification, it should be emphasized to ensure accurate processing: an <a
                                href="#anchor-file">Anchor File</a> <strong><strong>MUST NOT</strong></strong> include
                            multiple operations in the <code>operations</code> section of the <a
                                href="#anchor-file">Anchor File</a> for the same <a href="#did-suffix">DID Suffix</a> -
                            if any duplicates are found, cease processing, discard the file data, and retain a reference
                            that the file is to be ignored.</li>
                    </ul>
                </li>
                <li>
                    <p>If processing of rules 1 and 2 above resulted in successful validation of the Anchor File,
                        initiate retrieval of the <a href="#map-file">Map File</a> via the <a
                            href="#cas-protocol"><code>CAS_PROTOCOL</code></a> using the <a
                            href="#map-file-property"><code>map_file_uri</code></a> property’s <em>CAS URI</em> value,
                        if the <a href="#map-file-property"><code>map_file_uri</code></a> property is present. This is
                        only a <strong><strong>SUGGESTED</strong></strong> point at which to begin retrieval of the Map
                        File, not a blocking procedural step, so you may continue with processing before retrieval of
                        the <a href="#map-file">Map File</a> is complete.</p>
                </li>
                <li>
                    <p>Iterate the <a href="#anchor-file-create-entry"><em>Anchor File Create Entries</em></a>, and for
                        each entry, process as follows:</p>
                    <ol>
                        <li>Derive the <a href="#did-suffix">DID Suffix</a> from the values present in the entry.</li>
                        <li>Ensure the <a href="#did-suffix">DID Suffix</a> of the operation entry has not been included
                            in another valid operation that was previously processed in the scope of this Anchor File.
                            If another previous, valid operation was already processed in the scope of this <a
                                href="#anchor-file">Anchor File</a> for the same DID, do not process the operation and
                            move to the next operation in the array.</li>
                        <li>Create an entry for the operation within the <em>Operation Storage</em> area relative to the
                            <a href="#did-suffix">DID Suffix</a>.</li>
                    </ol>
                </li>
                <li>
                    <p>Iterate the <a href="#anchor-file-recovery-entry"><em>Anchor File Recovery Entries</em></a>, and
                        for each entry, process as follows:</p>
                    <ol>
                        <li>Ensure the <a href="#did-suffix">DID Suffix</a> of the operation entry has not been included
                            in another valid operation that was previously processed in the scope of this Anchor File.
                            If another previous, valid operation was already processed in the scope of this <a
                                href="#anchor-file">Anchor File</a> for the same DID, do not process the operation and
                            move to the next operation in the array.</li>
                        <li>Create an entry for the operation within the <em>Operation Storage</em> area relative to the
                            <a href="#did-suffix">DID Suffix</a>.</li>
                    </ol>
                </li>
                <li>
                    <p>Iterate the <a href="#anchor-file">Anchor File</a> <a
                            href="#anchor-file-deactivate-entry"><em>Deactivate Entries</em></a>, and for each entry,
                        process as follows:</p>
                    <ol>
                        <li>Ensure the <a href="#did-suffix">DID Suffix</a> of the operation entry has not been included
                            in another valid operation that was previously processed in the scope of this Anchor File.
                            If another previous, valid operation was already processed in the scope of this <a
                                href="#anchor-file">Anchor File</a> for the same DID, do not process the operation and
                            move to the next operation in the array.</li>
                        <li>Create an entry for the operation within the <em>Operation Storage</em> area relative to the
                            <a href="#did-suffix">DID Suffix</a>.</li>
                    </ol>
                    <!-- 2. Concatenate the [DID Suffix](#did-suffix) and the _Recovery Reveal Value_ together and validate the signature present in the entry against the concatenated string value. If the signature is valid, update retained references to the DID to deactivate it. If the signature is invalid, do not process the operation and move to the next operation in the array. -->
                </li>
            </ol>
            <div id="todo-1" class="notice todo"><a class="notice-link" href="#todo-1">TODO</a>
                <p>Confirm how we handle ops where there was not a previous op found.</p>
            </div>
            <h3 id="map-file-processing"><a class="toc-anchor" href="#map-file-processing">§</a> Map File Processing
            </h3>
            <p>The follow sequence of rules and processing steps must be followed to correctly process a Map File:</p>
            <ol>
                <li>The <a href="#map-file">Map File</a> <strong><strong>MUST NOT</strong></strong> exceed the <a
                        href="#max-map-file-size"><code>MAX_MAP_FILE_SIZE</code></a> - if it does, cease processing,
                    discard the file data, and retain a reference that the file is to be ignored.</li>
                <li>The <a href="#map-file">Map File</a> <strong><strong>MUST</strong></strong> validate against the
                    protocol-defined <a href="#map-file">Map File</a> schema and construction rules - if it DOES NOT,
                    cease processing, discard the file data, and retain a reference that the file is to be ignored.</li>
                <li>If processing of rules 1 and 2 above resulted in successful validation of the Map File, begin
                    retrieval of the Chunk Files by iterating the <code>chunks</code> array and using the <a
                        href="#cas-protocol"><code>CAS_PROTOCOL</code></a> to fetch each entry’s
                    <code>chunk_file_uri</code> (a <em>CAS URI</em> based on the <a
                        href="#cas-uri-algorithm"><code>CAS_URI_ALGORITHM</code></a>. This is only a
                    <strong><strong>SUGGESTED</strong></strong> point at which to begin retrieval of the Map File, not a
                    blocking procedural step, so you may continue with processing before retrieval of the Chunk File
                    chunks is complete.</li>
                <li>Iterate the <a href="#map-file-update-entry"><em>Map File Update Entries</em></a>, and for each
                    entry, process as follows:
                    <ol>
                        <li>Ensure the <a href="#did-suffix">DID Suffix</a> of the operation entry has not been included
                            in another valid operation that was previously processed in the scope of the <a
                                href="#map-file">Map File</a> or its parent <a href="#anchor-file">Anchor File</a>. If
                            another previous, valid operation was already processed in the scope of this <a
                                href="#anchor-file">Anchor File</a> for the same DID, do not process the operation and
                            move to the next operation in the array.</li>
                        <li>Ensure there IS NOT an existing, valid <a href="#map-file-update-entry">Map File Update
                                Entry</a> for the same <a href="#did-suffix">DID Suffix</a>, with the same update reveal
                            value, at a previous logical time in the implementation node’s observed state-history: If
                            another valid <a href="#map-file-update-entry">Map File Update Entry</a> has already update
                            a DID matching the same <a href="#did-suffix">DID Suffix</a>, using the same update
                            commitment in any previously observed transaction preceding the current transaction in <a
                                href="#ledger-time">Ledger Time</a>, do not process the operation and move to the next
                            operation in the array.</li>
                        <li>Create an entry for the operation within the <em>Operation Storage</em> area relative to the
                            <a href="#did-suffix">DID Suffix</a>.</li>
                    </ol>
                </li>
                <li>If the node is in a <a href="#light-node"><em>Light Node</em></a> configuration, retain a reference
                    to the <a href="#chunk-files">Chunk Files</a> relative to the DIDs in the anchored batch for
                    just-in-time fetch of the <a href="#chunk-files">Chunk Files</a> during DID resolution.</li>
            </ol>
            <h3 id="chunk-file-processing"><a class="toc-anchor" href="#chunk-file-processing">§</a> Chunk File
                Processing</h3>
            <p>The follow sequence of rules and processing steps must be followed to correctly process a Chunk File
                chunk:</p>
            <ol>
                <li>The <a href="#chunk-file">Chunk File</a> chunk <strong><strong>MUST NOT</strong></strong> exceed the
                    <a href="#max-chunk-file-size"><code>MAX_CHUNK_FILE_SIZE</code></a> - if it does, cease processing,
                    discard the file data, and retain a reference that the file is to be ignored.</li>
                <li>The <a href="#chunk-file">Chunk File</a> <strong><strong>MUST</strong></strong> validate against the
                    protocol-defined <a href="#chunk-file">Chunk File</a> schema and construction rules - if it DOES
                    NOT, cease processing, discard the file data, and retain a reference that the file is to be ignored.
                </li>
                <li>In order to process <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entries</em></a> in
                    relation to the DIDs they are bound to, they must be mapped back to the Create, Recovery, and Update
                    operation entries present in the <a href="#anchor-file">Anchor File</a> and <a href="#map-file">Map
                        File</a>. To create this mapping, concatenate the <a href="#anchor-file-create-entry"><em>Anchor
                            File Create Entries</em></a>, <a href="#anchor-file-recovery-entry"><em>Anchor File Recovery
                            Entries</em></a>, <a href="#map-file-recovery-entry"><em>Map File Update Entries</em></a>
                    into a single array, in that order, herein referred to as the <a
                        href="#operation-delta-mapping-array" id="operation-delta-mapping-array">Operation Delta Mapping
                        Array</a>. Pseudo-code example:
                    <pre class="language-js"><code class="language-js"><span class="token keyword">let</span> mappingArray <span class="token operator">=</span> <span class="token punctuation">[</span><span class="token punctuation">]</span><span class="token punctuation">.</span><span class="token function">concat</span><span class="token punctuation">(</span><span class="token constant">CREATE_ENTRIES</span><span class="token punctuation">,</span> <span class="token constant">RECOVERY_ENTRIES</span><span class="token punctuation">,</span> <span class="token constant">UPDATE_ENTRIES</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
</code></pre>
                </li>
                <li>With the <a href="#operation-delta-mapping-array">Operation Delta Mapping Array</a> assembled,
                    iterate the <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entries</em></a> from 0 index
                    forward, processing each <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a> as
                    follows:
                    <ol>
                        <li>Identify the operation entry from the <a href="#operation-delta-mapping-array">Operation
                                Delta Mapping Array</a> at the same index as the current iteration and determine its <a
                                href="#did-suffix">DID Suffix</a> (for <a href="#anchor-file-create-entry"><em>Anchor
                                    File Create Entries</em></a>, you will need to compute the <a href="#did-suffix">DID
                                Suffix</a>). This is the DID the current iteration element maps to.</li>
                        <li>Store the current <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>
                            relative to its operation entry in the persistent storage area designated for the related <a
                                href="#did-suffix">DID Suffix</a>.</li>
                    </ol>
                </li>
            </ol>
            <div id="note-4" class="notice note"><a class="notice-link" href="#note-4">NOTE</a>
                <p>The assembly and processing of Chunk Files will change in a future update to the protocol, to
                    accommodate the introduction of multiple chunk files. The current protocol version is designed
                    around one Chunk File, but the scaffolding is present to move to multiple Chunk Files as development
                    progresses.</p>
            </div>
            <div id="todo-2" class="notice todo"><a class="notice-link" href="#todo-2">TODO</a>
                <p>Add the ordering rules for ensuring the order matches the order expected from the Anchor/Map files
                </p>
            </div>
            <h2 id="proof-of-fee"><a class="toc-anchor" href="#proof-of-fee">§</a> Proof of Fee</h2>
            <p>Sidetree implementers <strong><strong>MAY</strong></strong> choose to implement this section of
                protective mechanisms, which are designed to strengthen a Sidetree network against low-cost spurious
                operations. These mechanisms are primarily designed for open, permissionless implementations utilizing
                public blockchains that feature native crypto-economic systems.</p>
            <h3 id="base-fee-variable"><a class="toc-anchor" href="#base-fee-variable">§</a> Base Fee Variable</h3>
            <p>All of the mechanisms described in this section are based on the same underlying numeric value, known as
                the <em>Base Fee Variable</em>, that is calculated by processing a collection of native variables from
                the target ledger with a set of deterministic functions. The <em>Base Fee Variable</em> is used in two
                primary ways: 1) to set a minimum required native transaction fee that must be paid relative to the
                number of DID operations a writer seeks to anchor with the transaction, and 2) the fee basis that is
                used to deterministically set a economic locking amount based on the size of operational batches a
                writer wants to access.</p>
            <p>To calculate the <em>Base Fee Variable</em>, every node <strong><strong>MUST</strong></strong> run the
                following pseudorandom transaction selection routine across the transaction history of the target
                ledger, which will produce the same selected set of transactions across all nodes:</p>
            <h3 id="per-operation-fee"><a class="toc-anchor" href="#per-operation-fee">§</a> Per-Operation Fee</h3>
            <p>…</p>
            <h3 id="value-locking"><a class="toc-anchor" href="#value-locking">§</a> Value Locking</h3>
            <p>…</p>
            <h2 id="resolution"><a class="toc-anchor" href="#resolution">§</a> Resolution</h2>
            <h3 id="operation-compilation"><a class="toc-anchor" href="#operation-compilation">§</a> Operation
                Compilation</h3>
            <ol>
                <li>
                    <p>Upon invocation of resolution, retrieve all observed operations for the <a
                            href="#did-unique-suffix">DID Unique Suffix</a> of the DID URI being resolved.</p>
                </li>
                <li>
                    <p>If record of the DID being published has been observed, proceed to Step 3. If there is no
                        observed record of the DID being published, skip all remaining <a
                            href="#operation-compilation">Operation Compilation</a> steps and process the DID as
                        follows:</p>
                    <ol>
                        <li>If the DID URI <strong><strong>does not</strong></strong> include a
                            <code>initial-state</code> <em>DID URL Parameter</em> with a Method-specific prefix that
                            matches the name of the implementation, abort resolution and return <em>Unresolvable</em>.
                        </li>
                        <li>If the DID URI <strong><strong>does</strong></strong> include a <code>initial-state</code>
                            <em>DID URL Parameter</em> with a Method-specific prefix that matches the name of the
                            implementation, process the DID as follows:
                            <ol>
                                <li>Split the <code>initial-state</code> <em>DID URL Parameter</em> string value by the
                                    period (<code>.</code>) character, and ensure the resulting array contains
                                    <strong><strong>exactly</strong></strong> two (2) members. If the resulting array
                                    contains fewer than two members, abort resolution and return <em>Unresolvable</em>.
                                </li>
                                <li>Using the implementation’s <a
                                        href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>, decode the
                                    both members of the array and retain the resulting values. If the values fail to
                                    properly decode in accordance with the implementation’s <a
                                        href="#data-encoding-scheme"><code>DATA_ENCODING_SCHEME</code></a>, abort
                                    resolution and return <em>Unresolvable</em>.</li>
                                <li>Let the decoded value at the 0 index be the DID’s <a
                                        href="#create-suffix-data-object"><em>Create Operation Suffix Data
                                            Object</em></a>, and validate it as such. If the value is found to be a
                                    valid <a href="#create-suffix-data-object"><em>Create Operation Suffix Data
                                            Object</em></a>, proceed, if the value fails validation, abort resolution
                                    and return <em>Unresolvable</em>.</li>
                                <li>Let the decoded value at the 0 index be the DID’s <a
                                        href="#create-delta-object"><em>Create Operation Delta Object</em></a> (which is
                                    present in a <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>
                                    for published, anchored DIDs), and validate it as such. If the value is found to be
                                    a valid <a href="#create-delta-object"><em>Create Operation Delta Object</em></a> ,
                                    proceed, if the value fails validation, abort resolution and return
                                    <em>Unresolvable</em>.</li>
                                <li>If all steps above are successful, internally flag the state of the DID as
                                    <em>Unpublished</em> and continue to Step 4 of the Operation Compilation process (<a
                                        href="#create-operation-processing">create operation processing</a>) as if the
                                    values decoded and validated in the steps above represent the only operation
                                    associated with the DID.</li>
                            </ol>
                        </li>
                    </ol>
                </li>
                <li>
                    <p><a href="#operation-hash-map-construction" id="operation-hash-map-construction">Assembly of the
                            <em>Operation Hash Map</em></a>: if no entries are present in the DID’s <em>Operation
                            Storage</em> area without the <em>Mapped</em> flag, proceed to the next step, if entries do
                        exist in the DID’s <em>Operation Storage</em> begin iterating them forward from 0-index as
                        follows:</p>
                    <ol>
                        <li>If the entry is a <a href="#create">Create</a> operation, create a persistent <a
                                href="#create-operation-pool" id="create-operation-pool"><em>Create Operation
                                    Pool</em></a> reference for it, and all other Create-type operations found during
                            this iteration.</li>
                        <li>If the entry is not a <a href="#create">Create</a> operation, derive the <em>Map Hash</em>
                            as follows:
                            <ul>
                                <li>If the entry is a <a href="#recover">Recovery</a> or <a
                                        href="#deactivate">Deactivate</a> operation, hash the <a
                                        href="https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17">JCS
                                        canonicalized</a> <a href="https://tools.ietf.org/html/rfc7517">IETF RFC
                                        7517</a> JWK representation value of the entry’s <code>recovery_key</code>
                                    property using the <a href="#hashing-process">Hashing Process</a> and let the
                                    resulting hash value be the <em>Map Hash</em>.</li>
                                <li>If the entry is an <a href="#update">Update</a> operation, hash the value of the
                                    entry’s <code>update_key</code> property using the <a
                                        href="#hashing-process">Hashing Process</a> and let the resulting hash value be
                                    the <em>Map Hash</em>.</li>
                            </ul>
                        </li>
                        <li>Ensure a key exists in the <em>Operation Hash Map</em> corresponding to the <em>Map
                                Hash</em>, and that the corresponding value is an array. If no property exists for the
                            <em>Map Hash</em>, create one and let its value be an array.</li>
                        <li>Insert the entry into the array of the <em>Map Hash</em> at its proper position in ascending
                            <a href="#ledger-time"><code>Ledger Time</code></a> order.</li>
                        <li>Mark the entry in the <em>Operation Storage</em> area with the <em>Mapped</em> flag.</li>
                    </ol>
                </li>
                <li>
                    <p><a href="#create-operation-processing" id="create-operation-processing">Create operation
                            processing</a>: If no operations are present in the <a
                            href="#create-operation-pool"><em>Create Operation Pool</em></a>, cease resolution of the
                        DID and declare the DID <em>Unresolvable</em>. If the <a
                            href="#create-operation-pool"><em>Create Operation Pool</em></a> contains operation entries,
                        process them as follows:</p>
                    <ol>
                        <li>If a <em>Next Recovery Commitment</em> value has not already been stored in relation to the
                            DID, store the value of the <code>recovery_commitment</code> property from the entry’s <a
                                href="#create-suffix-data-object"><em>Create Operation Suffix Data Object</em></a> as
                            the <em>Next Recovery Commitment</em> for use in processing the next Recovery operation.
                        </li>
                        <li>Retrieve the <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a> from the
                            pre-processed <a href="#chunk-file">Chunk File</a> associated with the operation and proceed
                            to the processing instruction, or, if the <a href="#chunk-file">Chunk File</a> has not yet
                            been retrieved and processed (i.e. node is a <a href="#light-node"><em>Light Node</em></a>
                            implementation, file was previously unavailable, etc.), perform the following steps:
                            <ol>
                                <li>Using the <a href="#cas-protocol"><code>CAS_PROTOCOL</code></a>, fetch the <a
                                        href="#chunk-files">Chunk File</a> using the associated <em>Chunk File URI</em>.
                                    If the file is unable to be retrieved:
                                    <ol>
                                        <li>Set the <em>Next Update Commitment</em> value to <code>null</code>.</li>
                                        <li>Skip all further Create operation processing steps and proceed to <a
                                                href="#post-create-operation-processing">post-Create operation
                                                processing</a>.</li>
                                    </ol>
                                </li>
                                <li>Validate the <a href="#chunk-file">Chunk File</a> using the <a
                                        href="#chunk-file-processing">Chunk File Processing</a> procedure. If the <a
                                        href="#chunk-file">Chunk File</a> is valid, proceed, if the file is invalid:
                                    <ol>
                                        <li>Set the <em>Next Update Commitment</em> value to <code>null</code>.</li>
                                        <li>Skip all further Create operation processing steps and proceed to <a
                                                href="#post-create-operation-processing">post-Create operation
                                                processing</a>.</li>
                                    </ol>
                                </li>
                            </ol>
                        </li>
                        <li>Validate the <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>. If the
                            <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a> is valid, proceed, if
                            the Entry is invalid, let the state of the DID reflect an <em>Empty DID State</em>.</li>
                        <li>Generate a hash of the decoded <a href="#chunk-file-delta-entry"><em>Chunk File Delta
                                    Entry</em></a> via the <a href="#hashing-process">Hashing Process</a> and ensure the
                            hash equals the value of the <a href="#create-suffix-data-object"><em>Create Operation
                                    Suffix Data Object</em></a> <code>delta_hash</code> property. If the values are
                            exactly equal, proceed, if they are not:
                            <ol>
                                <li>Set the <em>Next Update Commitment</em> value to <code>null</code>.</li>
                                <li>Skip all further Create operation processing steps and proceed to <a
                                        href="#post-create-operation-processing">post-Create operation processing</a>.
                                </li>
                            </ol>
                        </li>
                        <li>Store the <code>update_commitment</code> value of the <a
                                href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a> as the <em>Next
                                Update Commitment</em> for use in processing the next Update operation.</li>
                        <li>Begin iterating the <code>patches</code> array in the <a
                                href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>, and for each <a
                                href="#did-state-patch">DID State Patch</a> entry, perform the following steps:
                            <ol>
                                <li>Validate the entry in accordance any requirements imposed by the <a
                                        href="#standard-patch-actions">Patch Action</a> type indicated by the
                                    <code>action</code> value of the entry. If the entry is valid, proceed, if the entry
                                    fails validation, skip the entry and proceed to the next entry.</li>
                                <li>Apply the patch as directed by the <a href="#standard-patch-actions">Patch
                                        Action</a> type specified by the <code>action</code> property. If any part of
                                    the patch fails or produces an error, reverse all modifications to the DID’s state
                                    and proceed to the next entry.</li>
                            </ol>
                        </li>
                    </ol>
                </li>
                <li>
                    <p><a href="#recovery-deactivate-operation-processing"
                            id="recovery-deactivate-operation-processing">Recovery and deactivate operation
                            processing</a>: when Create operations have been successfully processed, process any <a
                            href="#recover">Recovery</a> and <a href="#deactivate">Deactivate</a> operations that may
                        exist in the <em>Operation Hash Map</em> using the following processing loop:</p>
                    <ol>
                        <li>If a property is present in the <em>Operation Hash Map</em> that matches the <em>Next
                                Recovery Commitment</em> exactly, process its array of operation entries using the
                            following steps. If no property exists in the <em>Operation Hash Map</em> that matches the
                            <em>Next Recovery Commitment</em> exactly, exit <a
                                href="#recovery-deactivate-operation-processing">recovery and deactivate operation
                                processing</a> and advance to <a href="#update-operation-processing">update operation
                                processing</a>.</li>
                        <li>Iterate the array of operation entries forward from 0-index using the process enumerated
                            below until a valid entry is found and processed:
                            <ul>
                                <li>
                                    <p>If the entry is a <a href="#recover">Recovery</a> operation:</p>
                                    <ol>
                                        <li>Use the <code>recovery_key</code> value of the <a
                                                href="#recovery-signed-data-object"><em>Recovery Operation Signed Data
                                                    Object</em></a> to validate its JWS signature. If the signature is
                                            valid, proceed, if the signature is invalid, skip the entry and iterate
                                            forward to the next entry. If there are no further operation entries, and
                                            the <em>Next Update Commitment</em> value
                                            <strong><strong>IS</strong></strong> set to <code>null</code>, proceed to <a
                                                href="#compiled-state-processing">compiled state processing</a>. If the
                                            <em>Next Update Commitment</em> value <strong><strong>IS
                                                    NOT</strong></strong> set to <code>null</code>, proceed to <a
                                                href="#update-operation-processing">update operation processing</a>.
                                        </li>
                                        <li>Store the <code>recovery_commitment</code> value of the <a
                                                href="#recovery-signed-data-object"><em>Recovery Operation Signed Data
                                                    Object</em></a> as the new value for the <em>Next Recovery
                                                Commitment</em>, for use in processing the next <a
                                                href="#recover">Recovery</a> operation.</li>
                                        <li>Retrieve the <a href="#chunk-file-delta-entry"><em>Chunk File Delta
                                                    Entry</em></a> from the pre-processed <a href="#chunk-file">Chunk
                                                File</a> associated with the operation and proceed to the processing
                                            instruction, or, if the <a href="#chunk-file">Chunk File</a> has not yet
                                            been retrieved and processed (e.g. node is a <a href="#light-node"><em>Light
                                                    Node</em></a> implementation), perform the following steps:
                                            <ol>
                                                <li>Using the <a href="#cas-protocol"><code>CAS_PROTOCOL</code></a>,
                                                    fetch the <a href="#chunk-files">Chunk File</a> data using the
                                                    associated <em>Chunk File URI</em>. If the file data is able to be
                                                    retrieved, proceed, if the file cannot be found:
                                                    <ol>
                                                        <li>Set the <em>Next Update Commitment</em> value to
                                                            <code>null</code>.</li>
                                                        <li>Use the new <em>Next Recovery Commitment</em> in another run
                                                            of the <a
                                                                href="#recovery-deactivate-operation-processing">recovery
                                                                and deactivate operation processing</a> loop.</li>
                                                    </ol>
                                                </li>
                                                <li>Validate the <a href="#chunk-file">Chunk File</a> using the <a
                                                        href="#chunk-file-processing">Chunk File Processing</a>
                                                    procedure. If the <a href="#chunk-file">Chunk File</a> is valid,
                                                    proceed, if the file is invalid:
                                                    <ol>
                                                        <li>Set the <em>Next Update Commitment</em> value to
                                                            <code>null</code>.</li>
                                                        <li>Use the new <em>Next Recovery Commitment</em> in another run
                                                            of the <a
                                                                href="#recovery-deactivate-operation-processing">recovery
                                                                and deactivate operation processing</a> loop.</li>
                                                    </ol>
                                                </li>
                                            </ol>
                                        </li>
                                        <li>Validate the <a href="#chunk-file-delta-entry"><em>Chunk File Delta
                                                    Entry</em></a>. If the <a href="#chunk-file-delta-entry"><em>Chunk
                                                    File Delta Entry</em></a> is valid, proceed, if the entry is
                                            invalid:
                                            <ol>
                                                <li>Let the state of the DID reflect an <em>Empty DID State</em>.</li>
                                                <li>Use the new <em>Next Recovery Commitment</em> in another run of the
                                                    <a href="#recovery-deactivate-operation-processing">recovery and
                                                        deactivate operation processing</a> loop.</li>
                                            </ol>
                                        </li>
                                        <li>Generate a hash of the decoded <a href="#chunk-file-delta-entry"><em>Chunk
                                                    File Delta Entry</em></a> via the <a href="#hashing-process">Hashing
                                                Process</a> and ensure the hash equals the value of the <a
                                                href="#recovery-signed-data-object"><em>Recovery Operation Signed Data
                                                    Object</em></a> <code>delta_hash</code> property. If the values are
                                            exactly equal, proceed, if the values are not exactly equal:
                                            <ol>
                                                <li>Set the <em>Next Update Commitment</em> value to <code>null</code>.
                                                </li>
                                                <li>Use the new <em>Next Recovery Commitment</em> in another run of the
                                                    <a href="#recovery-deactivate-operation-processing">recovery and
                                                        deactivate operation processing</a> loop.</li>
                                            </ol>
                                        </li>
                                        <li>Assign the <code>update_commitment</code> value of the <a
                                                href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a> as
                                            the new value for the <em>Next Update Commitment</em>, for use in processing
                                            the next Update operation.</li>
                                        <li>Begin iterating the <code>patches</code> array in the <a
                                                href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>, and
                                            for each <a href="#did-state-patch">DID State Patch</a> entry, perform the
                                            following steps:
                                            <ol>
                                                <li>Validate the entry in accordance any requirements imposed by the <a
                                                        href="#standard-patch-actions">Patch Action</a> type indicated
                                                    by the <code>action</code> value of the entry. If the entry is
                                                    valid, proceed, if the entry fails validation, use the new <em>Next
                                                        Recovery Commitment</em> in another run of the <a
                                                        href="#recovery-deactivate-operation-processing">recovery and
                                                        deactivate operation processing</a> loop.</li>
                                                <li>Apply the patch as directed by the <a
                                                        href="#standard-patch-actions">Patch Action</a> type specified
                                                    by the <code>action</code> property. If any part of the patch fails
                                                    or produces an error, reverse all modifications to the DID’s state
                                                    and use the new <em>Next Recovery Commitment</em> in another run of
                                                    the <a href="#recovery-deactivate-operation-processing">recovery and
                                                        deactivate operation processing</a> loop.</li>
                                            </ol>
                                        </li>
                                    </ol>
                                </li>
                                <li>
                                    <p>If the entry is a <a href="#deactivate">Deactivate</a> operation:</p>
                                    <ol>
                                        <li>Use the <code>recovery_key</code> value of the <a
                                                href="#deactivate-signed-data-object"><em>Deactivate Operation Signed
                                                    Data Object</em></a> to validate its JWS signature. If the signature
                                            is valid, proceed, if the signature is invalid, skip the entry and iterate
                                            forward to the next entry.</li>
                                        <li>The <a href="#deactivate-signed-data-object"><em>Deactivate Operation Signed
                                                    Data Object</em></a> <strong><strong>must</strong></strong> include
                                            a <code>did_suffix</code> property with a value that exactly equal to the <a
                                                href="#did-suffix">DID Suffix</a> of the DID being operated on, if the
                                            value is not exactly equal, skip the entry and proceed to the next
                                            operation.</li>
                                        <li>Set the <em>Next Update Commitment</em> value to <code>null</code>, mark the
                                            DID as <em>Deactivated</em>, and process no further operation entries for
                                            this DID.</li>
                                    </ol>
                                </li>
                            </ul>
                        </li>
                    </ol>
                </li>
                <li>
                    <p><a href="#update-operation-processing">Update operation processing</a>: if the DID is marked as
                        <em>Deactivated</em> or the <em>Next Update Commitment</em> value
                        <strong><strong>IS</strong></strong> set to <code>null</code>, skip <a href="#update">Update</a>
                        processing and proceed to <a href="#compiled-state-processing">compiled state processing</a>. If
                        the <em>Next Update Commitment</em> value <strong><strong>IS NOT</strong></strong> set to
                        <code>null</code> and no <a href="#deactivate">Deactivate</a> operations were successfully
                        processed during <a href="#recovery-deactivate-operation-processing">recovery and deactivate
                            operation processing</a>, process any Update operations that may exist in the <em>Operation
                            Hash Map</em> using the following processing loop:</p>
                    <ol>
                        <li>
                            <p>If a property is present in the <em>Operation Hash Map</em> that matches the <em>Next
                                    Update Commitment</em> exactly, process its array of operation entries using the
                                following steps. If no property exists in the <em>Operation Hash Map</em> that matches
                                the <em>Next Recovery Commitment</em> exactly, exit <a
                                    href="#update-operation-processing">update operation processing</a> and advance to
                                <a href="#compiled-state-processing">compiled state processing</a>.</p>
                        </li>
                        <li>
                            <p>Iterate the array of operation entries forward from 0-index using the process enumerated
                                below until a valid entry is found and processed:</p>
                            <ol>
                                <li>Using the revealed <code>update_key</code> JWK value, validate the <a
                                        href="#update-signed-data-object"><em>Update Operation Signed Data
                                            Object</em></a> signature. If the signature is valid, proceed, if the
                                    signature is invalid, skip the entry and iterate forward to the next operation.</li>
                                <li>Retrieve the <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>
                                    from the pre-processed <a href="#chunk-file">Chunk File</a> associated with the
                                    operation and proceed to the processing instruction, or, if the <a
                                        href="#chunk-file">Chunk File</a> has not yet been retrieved and processed (i.e.
                                    node is a <a href="#light-node"><em>Light Node</em></a> implementation, file was
                                    previously unavailable, etc.), perform the following steps:
                                    <ol>
                                        <li>Using the <a href="#cas-protocol"><code>CAS_PROTOCOL</code></a>, fetch the
                                            <a href="#chunk-files">Chunk File</a> using the associated <em>Chunk File
                                                URI</em>. If the file is unable to be retrieved:
                                            <ol>
                                                <li>Set the <em>Next Update Commitment</em> value to <code>null</code>.
                                                </li>
                                                <li>Exit <a href="#update-operation-processing">update operation
                                                        processing</a> and advance to <a
                                                        href="#compiled-state-processing">compiled state processing</a>.
                                                </li>
                                            </ol>
                                        </li>
                                        <li>Validate the <a href="#chunk-file">Chunk File</a> using the <a
                                                href="#chunk-file-processing">Chunk File Processing</a> procedure. If
                                            the <a href="#chunk-file">Chunk File</a> is valid, proceed, if the file is
                                            invalid:
                                            <ol>
                                                <li>Set the <em>Next Update Commitment</em> value to <code>null</code>.
                                                </li>
                                                <li>Exit <a href="#update-operation-processing">update operation
                                                        processing</a> and advance to <a
                                                        href="#compiled-state-processing">compiled state processing</a>.
                                                </li>
                                            </ol>
                                        </li>
                                    </ol>
                                </li>
                                <li>Validate the <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>.
                                    If the <a href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a> is
                                    valid, proceed, if the entry is invalid, let the state of the DID reflect an
                                    <em>Empty DID State</em>.</li>
                                <li>Generate a hash of the decoded <a href="#chunk-file-delta-entry"><em>Chunk File
                                            Delta Entry</em></a> via the <a href="#hashing-process">Hashing Process</a>
                                    and ensure the hash equals the value of the <a
                                        href="#update-signed-data-object"><em>Update Operation Signed Data
                                            Object</em></a> <code>delta_hash</code> property. If the values are exactly
                                    equal, proceed, if they are not:
                                    <ol>
                                        <li>Set the <em>Next Update Commitment</em> value to <code>null</code>.</li>
                                        <li>Exit <a href="#update-operation-processing">update operation processing</a>
                                            and advance to <a href="#compiled-state-processing">compiled state
                                                processing</a>.</li>
                                    </ol>
                                </li>
                                <li>Store the <code>update_commitment</code> value of the <a
                                        href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a> as the
                                    <em>Next Update Commitment</em> for use in processing the next Update operation.
                                </li>
                                <li>Begin iterating the <code>patches</code> array in the <a
                                        href="#chunk-file-delta-entry"><em>Chunk File Delta Entry</em></a>, and for each
                                    <a href="#did-state-patch">DID State Patch</a> entry, perform the following steps:
                                    <ol>
                                        <li>Validate the entry in accordance any requirements imposed by the <a
                                                href="#standard-patch-actions">Patch Action</a> type indicated by the
                                            <code>action</code> value of the entry. If the entry is valid, proceed, if
                                            the entry fails validation, exit <a
                                                href="#update-operation-processing">update operation processing</a> and
                                            advance to <a href="#compiled-state-processing">compiled state
                                                processing</a>.</li>
                                        <li>Apply the patch as directed by the <a href="#standard-patch-actions">Patch
                                                Action</a> type specified by the <code>action</code> property. If any
                                            part of the patch fails or produces an error, reverse all modifications to
                                            the DID’s state and exit <a href="#update-operation-processing">update
                                                operation processing</a> and advance to <a
                                                href="#compiled-state-processing">compiled state processing</a>.</li>
                                    </ol>
                                </li>
                            </ol>
                        </li>
                    </ol>
                </li>
                <li>
                    <p><a href="#compiled-state-processing" id="compiled-state-processing">Compiled state
                            processing</a>: After the DID’s operations have been evaluated in the compilation steps
                        above, the implementation <strong><strong>MUST</strong></strong> use the DID’s compiled state to
                        generate a valid DID Document in accordance with the <a
                            href="https://w3c.github.io/did-core/">W3C Decentralized Identifiers</a> specification.</p>
                </li>
                <li>
                    <p>If the DID Document is being rendered in the JSON-LD representation variant, the implementer
                        <strong><strong>SHOULD</strong></strong> add an <code>@base</code> entry to the document’s
                        <code>@context</code>, and set the <code>@base</code> value to the <code>id</code> of the
                        resolved DID. This ensures relative path values in the output DID Document are correctly
                        projected into id-related strings by JSON-LD parsers.</p>
                </li>
                <li>
                    <p>Once a valid DID Document state has been generated, proceed to the <a
                            href="#did-resolver-output">DID Resolver Output</a> process, if you intend to output the
                        resolved DID Document in accordance with the <a
                            href="#https://w3c-ccg.github.io/did-resolution/">Decentralized Identifier Resolution</a>
                        specification.</p>
                </li>
            </ol>
            <h3 id="did-resolver-output"><a class="toc-anchor" href="#did-resolver-output">§</a> DID Resolver Output
            </h3>
            <p>The following describes how to construct <a
                    href="#https://w3c-ccg.github.io/did-resolution/">Decentralized Identifier Resolution</a>-compliant
                <em>Resolution Result</em> based on a DID resolved via the <a href="#operation-compilation">Operation
                    Compilation</a> process described in the section above.</p>
            <p>If the compiled DID <strong><strong>was not</strong></strong> determined to be <em>Unresolvable</em>, as
                defined in the <a href="#operation-compilation">Operation Compilation</a> process above, proceed as
                follows:</p>
            <ol>
                <li>Generate a JSON object for the <em>Resolution Result</em>, structured in accordance with the <a
                        href="https://w3c-ccg.github.io/did-resolution/#example-14-example-did-resolution-result">Decentralized
                        Identifier Resolution</a> specification.</li>
                <li>Set the <code>didDocument</code> property of the <em>Resolution Result</em> object to the resolved
                    DID Document generated via the <a href="#operation-compilation">Operation Compilation</a> process.
                </li>
                <li>The <em>Resolution Result</em> object <strong><strong>MUST</strong></strong> include a
                    <code>methodMetadata</code> property, and its value <strong><strong>MUST</strong></strong> be an
                    object.</li>
                <li>The <em>Resolution Result</em> <code>methodMetadata</code> object
                    <strong><strong>MUST</strong></strong> include a <code>published</code> property with a boolean
                    value. If the compiled DID state is flagged as <em>Unpublished</em> and/or <em>Unresolvable</em>
                    (per the <a href="#operation-compilation">Operation Compilation</a> process), the
                    <code>published</code> property <strong><strong>MUST</strong></strong> be set to <code>false</code>,
                    otherwise, set the value to <code>true</code>.</li>
                <li>The <em>Resolution Result</em> <code>methodMetadata</code> object
                    <strong><strong>MUST</strong></strong> include an <code>updateCommitment</code> property, and its
                    value <strong><strong>MUST</strong></strong> be the <code>update_commitment</code> hash value
                    expected to be fulfilled in with the next <code>update_key</code> revealed in the next <a
                        href="#update">Update</a> operation.</li>
                <li>The <em>Resolution Result</em> <code>methodMetadata</code> object
                    <strong><strong>MUST</strong></strong> include an <code>recoveryCommitment</code> property, and its
                    value <strong><strong>MUST</strong></strong> be the <code>recovery_commitment</code> hash value
                    expected to be fulfilled in with the next <code>recovery_key</code> revealed in the next <a
                        href="#recover">Recovery</a> operation.</li>
            </ol>
            <h4 id="unresolvable-dids"><a class="toc-anchor" href="#unresolvable-dids">§</a> Unresolvable DIDs</h4>
            <p>…</p>
            <h3 id="late-publishing"><a class="toc-anchor" href="#late-publishing">§</a> Late Publishing</h3>
            <p>Sidetree is an eventually strongly consistent, conflict-free resolution system based on cryptographically
                signed, delta-based DID operations, which derives its deterministic order of operations from the
                position of operation entries in a decentralized ledger’s immutable linear chronology. Unlike the native
                tokens of a strongly immutable blockchain (e.g. Bitcoin), DIDs represent unique identifiers that are
                generally intended to be <em>non-transferrable</em>. As such, the Sidetree protocol provides no
                technical mechanism for exchanging ownership of DIDs with ‘double-spend’ assurance, the way one might do
                with a fungible cryptocurrency token.</p>
            <p>For Sidetree, <em>non-transferrability</em> manifests in a distinct way: a DID owner is ultimately in
                control of their past, present, and future state changes, and can expose state change operations as they
                choose across the lineage of their DID’s operational history. DID owners can create forks within
                <em>their own</em> DID state history, and nothing forces them to expose DID state operations they
                anchor. A DID operation anchored in the past, at Time X, can be exposed to sometime in the future, at
                Time Y. This means Sidetree nodes could become aware of past operations that create a change in the
                lineage of a DID - this is known as <em>Late Publishing</em> of a DID operation. However, due to the
                <em>non-transferrability</em> of DIDs, this condition is isolated to each DID’s own state lineage, and
                resolved by Sidetree’s deterministic ruleset, which guarantees only one fork of a DID’s state history
                can ever be valid. To better understand this, consider the following diagram that illustrates a DID
                owner, Alice, creating forks by creating and anchoring operations in the past that she does not expose
                to the network:</p>
            <div class="mermaid">graph TB
                0 --> 1
                1 --> 2a
                1 --> 2b
                2b --> 3</div>
            <p>As you can see above, Alice has created a fork by anchoring the divergent operations <code>2a</code> and
                <code>2b</code>. Let us assume Alice refrains from publishing the <a href="#file-structures">CAS
                    files</a> that other Sidetree nodes would detect to locate and replicate the date for operation
                <code>2a</code>, and further, assume Alice continues creating more operation history stemming from
                operation <code>2b</code>. Whenever Alice exposes the DID operation data for <code>2a</code>, other
                Sidetree nodes will need to decide which operation between <code>2a</code> and <code>2b</code> is the
                ‘right’ operation. The Sidetree protocol includes a strict rule that resolves this conflict, and any
                variation of it: the earliest operation in <a href="#ledger-time">Ledger Time</a> always wins. If
                operation <code>2a</code> precedes operation <code>2b</code> in <a href="#ledger-time">Ledger Time</a>,
                whenever she decides to publish operation <code>2a</code>, all other Sidetree nodes would process the
                operation and immediately deem operation <code>2a</code> to be the valid, correct operational fork. This
                remains true even if Alice continues building operational history stemming from operation
                <code>2b</code> any amount of time into the future.</p>
            <p>With this example of <em>late publishing</em> in mind, the most important aspect to remember is that DID
                owners decide what the PKI state of their DIDs should be, and remain in control of that state
                independent of the shape of their DID operational history. The net takeaway is that regardless of how a
                DID owner decides to update the state of their DID, the decision over what that state is remains
                entirely their choice.</p>
            <h2 id="method-versioning"><a class="toc-anchor" href="#method-versioning">§</a> Method Versioning</h2>
            <p>It is RECOMMENDED that Sidetree based DID Methods implement the following versioning structures to
                support development, testing, staging and production network deployments.</p>
            <p>We define a network suffix as follows for a given DID Method:</p>
            <p><code>did:&lt;method&gt;:&lt;network&gt;:&lt;didUniqueSuffix&gt;</code></p>
            <p>If no network suffix is provided, it is assumed that the “mainnet” or “production” network is to be used…
                for example, these DIDs should resolve to the same DID Document:</p>
            <pre><code>did:elem:mainnet:EiD0x0JeWXQbVIpBpyeyF5FDdZN1U7enAfHnd13Qk_CYpQ
did:elem:EiD0x0JeWXQbVIpBpyeyF5FDdZN1U7enAfHnd13Qk_CYpQ
</code></pre>
            <p>An ION DID on the Bitcoin Testnet3 testnet is defined as follows:</p>
            <p><code>did:ion:testnet3:EiD0x0JeWXQbVIpBpyeyF5FDdZN1U7enAfHnd13Qk_CYpQ</code></p>
            <p>An ELEM DID on the Ethereum Ropsten testnet is defined as follows:</p>
            <p><code>did:elem:ropsten:EiD0x0JeWXQbVIpBpyeyF5FDdZN1U7enAfHnd13Qk_CYpQ</code></p>
            <div id="ledger-forking" class="notice warning"><a class="notice-link" href="#ledger-forking">WARNING</a>
                <p>Implementers should be aware that if the underlying decentralized ledger system were to fork, the
                    identifiers will also be forked. In this case, the a new identifier must be created either through
                    an indication at the network layer or with a completely new method name to identify the
                    decentralized identifiers of the forked network.</p>
            </div>
            <h2 id="context"><a class="toc-anchor" href="#context">§</a> Context</h2>
            <p>Per the <a href="https://github.com/w3c/did-core">DID Core Spec</a> an <code>@context</code> MAY be used
                to represent a DID Document as Linked Data.</p>
            <p>If an <code>@context</code> is present, any properties not defined in DID Core,
                <strong><strong>MUST</strong></strong> be defined in this context, or in a DID Method specific one.</p>
            <p>For example:</p>
            <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
    <span class="token property">"@context"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
        <span class="token string">"https://www.w3.org/ns/did/v1"</span><span class="token punctuation">,</span> 
        <span class="token string">"https://identity.foundation/sidetree/context-v1.jsonld"</span><span class="token punctuation">,</span>
        <span class="token string">"https://example.com/method/specific.jsonld"</span>
    <span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            <h3 id="recovery"><a class="toc-anchor" href="#recovery">§</a> recovery</h3>
            <p>A verificationMethod used to support DID Document <a
                    href="https://identity.foundation/sidetree/spec/#recover">Recover Operation</a> verification.</p>
            <p>For Example:</p>
            <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
    <span class="token property">"@context"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
        <span class="token string">"https://www.w3.org/ns/did/v1"</span><span class="token punctuation">,</span> 
        <span class="token string">"https://identity.foundation/sidetree/context-v1.jsonld"</span>
    <span class="token punctuation">]</span><span class="token punctuation">,</span>
    <span class="token property">"recovery"</span><span class="token operator">:</span> <span class="token punctuation">[</span><span class="token punctuation">{</span>
      <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"did:example:123#JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw"</span><span class="token punctuation">,</span>
      <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"EcdsaSecp256k1VerificationKey2019"</span><span class="token punctuation">,</span>
      <span class="token property">"publicKeyJwk"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
        <span class="token property">"crv"</span><span class="token operator">:</span> <span class="token string">"secp256k1"</span><span class="token punctuation">,</span>
        <span class="token property">"kid"</span><span class="token operator">:</span> <span class="token string">"JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw"</span><span class="token punctuation">,</span>
        <span class="token property">"kty"</span><span class="token operator">:</span> <span class="token string">"EC"</span><span class="token punctuation">,</span>
        <span class="token property">"x"</span><span class="token operator">:</span> <span class="token string">"dWCvM4fTdeM0KmloF57zxtBPXTOythHPMm1HCLrdd3A"</span><span class="token punctuation">,</span>
        <span class="token property">"y"</span><span class="token operator">:</span> <span class="token string">"36uMVGM7hnw-N6GnjFcihWE3SkrhMLzzLCdPMXPEXlA"</span>
      <span class="token punctuation">}</span>
    <span class="token punctuation">}</span><span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            <h3 id="operation"><a class="toc-anchor" href="#operation">§</a> operation</h3>
            <p>A verificationMethod used to support verification of DID Document Operations: <a
                    href="https://identity.foundation/sidetree/spec/#create">Create</a>, <a
                    href="https://identity.foundation/sidetree/spec/#update">Update</a>, <a
                    href="https://identity.foundation/sidetree/spec/#deactivate">Deactivate</a>.</p>
            <p>For Example:</p>
            <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
    <span class="token property">"@context"</span><span class="token operator">:</span> <span class="token punctuation">[</span>
        <span class="token string">"https://www.w3.org/ns/did/v1"</span><span class="token punctuation">,</span> 
        <span class="token string">"https://identity.foundation/sidetree/context-v1.jsonld"</span>
    <span class="token punctuation">]</span><span class="token punctuation">,</span>
    <span class="token property">"operation"</span><span class="token operator">:</span> <span class="token punctuation">[</span><span class="token punctuation">{</span>
      <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"did:example:123#JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw"</span><span class="token punctuation">,</span>
      <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"EcdsaSecp256k1VerificationKey2019"</span><span class="token punctuation">,</span>
      <span class="token property">"publicKeyJwk"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
        <span class="token property">"crv"</span><span class="token operator">:</span> <span class="token string">"secp256k1"</span><span class="token punctuation">,</span>
        <span class="token property">"kid"</span><span class="token operator">:</span> <span class="token string">"JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw"</span><span class="token punctuation">,</span>
        <span class="token property">"kty"</span><span class="token operator">:</span> <span class="token string">"EC"</span><span class="token punctuation">,</span>
        <span class="token property">"x"</span><span class="token operator">:</span> <span class="token string">"dWCvM4fTdeM0KmloF57zxtBPXTOythHPMm1HCLrdd3A"</span><span class="token punctuation">,</span>
        <span class="token property">"y"</span><span class="token operator">:</span> <span class="token string">"36uMVGM7hnw-N6GnjFcihWE3SkrhMLzzLCdPMXPEXlA"</span>
      <span class="token punctuation">}</span>
    <span class="token punctuation">}</span><span class="token punctuation">]</span>
<span class="token punctuation">}</span>
</code></pre>
            <h3 id="usage"><a class="toc-anchor" href="#usage">§</a> usage</h3>
            <p>Deprecated. DO NOT USE.</p>
            <p>Was introduced to support key <code>ops</code> pre sidetree protocol spec v1.</p>
            <h3 id="publickeyjwk"><a class="toc-anchor" href="#publickeyjwk">§</a> publicKeyJwk</h3>
            <p>A public key in JWK format. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure
                that represents a cryptographic key. Read <a href="https://tools.ietf.org/html/rfc7517">RFC7517</a>.</p>
            <p>Example:</p>
            <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"did:example:123#JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw"</span><span class="token punctuation">,</span>
  <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"EcdsaSecp256k1VerificationKey2019"</span><span class="token punctuation">,</span>
  <span class="token property">"publicKeyJwk"</span><span class="token operator">:</span> <span class="token punctuation">{</span>
    <span class="token property">"crv"</span><span class="token operator">:</span> <span class="token string">"secp256k1"</span><span class="token punctuation">,</span>
    <span class="token property">"kid"</span><span class="token operator">:</span> <span class="token string">"JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw"</span><span class="token punctuation">,</span>
    <span class="token property">"kty"</span><span class="token operator">:</span> <span class="token string">"EC"</span><span class="token punctuation">,</span>
    <span class="token property">"x"</span><span class="token operator">:</span> <span class="token string">"dWCvM4fTdeM0KmloF57zxtBPXTOythHPMm1HCLrdd3A"</span><span class="token punctuation">,</span>
    <span class="token property">"y"</span><span class="token operator">:</span> <span class="token string">"36uMVGM7hnw-N6GnjFcihWE3SkrhMLzzLCdPMXPEXlA"</span>
  <span class="token punctuation">}</span>
<span class="token punctuation">}</span>
</code></pre>
            <h3 id="publickeyhex"><a class="toc-anchor" href="#publickeyhex">§</a> publicKeyHex</h3>
            <p>A hex encoded compressed public key.</p>
            <p>Example:</p>
            <pre class="language-json"><code class="language-json"><span class="token punctuation">{</span>
  <span class="token property">"id"</span><span class="token operator">:</span> <span class="token string">"did:example:123#JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw"</span><span class="token punctuation">,</span>
  <span class="token property">"type"</span><span class="token operator">:</span> <span class="token string">"EcdsaSecp256k1VerificationKey2019"</span><span class="token punctuation">,</span>
  <span class="token property">"publicKeyHex"</span><span class="token operator">:</span> <span class="token string">"027560af3387d375e3342a6968179ef3c6d04f5d33b2b611cf326d4708badd7770"</span>
<span class="token punctuation">}</span>
</code></pre>

        </article>

    </main>

    <slide-panels id="slidepanels">
        <slide-panel id="repo_issues" options="right">
            <header class="panel-header">
                <span>
                    <svg icon>
                        <use xlink:href="#github"></use>
                    </svg>
                    <span issue-count></span>
                </span>
                <span class="repo-issue-toggle" panel-toggle="repo_issues">✕</span>
            </header>
            <ul id="repo_issue_list"></ul>
        </slide-panel>

        <slide-panel id="toc">
            <header class="panel-header">
                <span>Table of Contents</span>
                <span panel-toggle="toc">✕</span>
            </header>
            <div id="toc_list">
                <ul class="toc">
                    <li><a href="#abstract">Abstract</a></li>
                    <li><a href="#introduction">Introduction</a></li>
                    <li><a href="#terminology">Terminology</a></li>
                    <li><a href="#protocol-versioning">Protocol Versioning</a>
                        <ul>
                            <li><a href="#version-segment-definitions">Version Segment Definitions</a></li>
                            <li><a href="#new-version-activation">New Version Activation</a></li>
                        </ul>
                    </li>
                    <li><a href="#default-parameters">Default Parameters</a></li>
                    <li><a href="#common-functions">Common Functions</a>
                        <ul>
                            <li><a href="#hashing-process">Hashing Process</a></li>
                            <li><a href="#commitment-schemes">Commitment Schemes</a>
                                <ul>
                                    <li><a href="#public-key-commitment-scheme">Public Key Commitment Scheme</a></li>
                                </ul>
                            </li>
                        </ul>
                    </li>
                    <li><a href="#network-topology">Network Topology</a></li>
                    <li><a href="#file-structures">File Structures</a>
                        <ul>
                            <li><a href="#anchor-file">Anchor File</a></li>
                            <li><a href="#map-file">Map File</a></li>
                            <li><a href="#chunk-files">Chunk Files</a></li>
                        </ul>
                    </li>
                    <li><a href="#did-uri-composition">DID URI Composition</a>
                        <ul>
                            <li><a href="#long-form-did-uris">Long-Form DID URIs</a></li>
                        </ul>
                    </li>
                    <li><a href="#json-web-signatures">JSON Web Signatures</a>
                        <ul>
                            <li><a href="#signing">Signing</a></li>
                            <li><a href="#verifying">Verifying</a>
                                <ul>
                                    <li><a href="#operation-verification">Operation Verification</a></li>
                                </ul>
                            </li>
                        </ul>
                    </li>
                    <li><a href="#did-operations">DID Operations</a>
                        <ul>
                            <li><a href="#create">Create</a></li>
                            <li><a href="#update">Update</a></li>
                            <li><a href="#recover">Recover</a></li>
                            <li><a href="#deactivate">Deactivate</a></li>
                        </ul>
                    </li>
                    <li><a href="#did-state-patches">DID State Patches</a>
                        <ul>
                            <li><a href="#standard-patch-actions">Standard Patch Actions</a>
                                <ul>
                                    <li><a href="#add-public-keys"><code>add-public-keys</code></a></li>
                                    <li><a href="#remove-public-keys"><code>remove-public-keys</code></a></li>
                                    <li><a href="#add-service-endpoints"><code>add-service-endpoints</code></a></li>
                                    <li><a href="#remove-service-endpoints"><code>remove-service-endpoints</code></a>
                                    </li>
                                    <li><a href="#replace"><code>replace</code></a></li>
                                    <li><a href="#ietf-json-patch"><code>ietf-json-patch</code></a></li>
                                </ul>
                            </li>
                        </ul>
                    </li>
                    <li><a href="#transaction-operation-processing">Transaction &amp; Operation Processing</a>
                        <ul>
                            <li><a href="#transaction-anchoring">Transaction Anchoring</a></li>
                            <li><a href="#cas-file-propagation">CAS File Propagation</a></li>
                            <li><a href="#transaction-processing">Transaction Processing</a></li>
                            <li><a href="#anchor-file-processing">Anchor File Processing</a></li>
                            <li><a href="#map-file-processing">Map File Processing</a></li>
                            <li><a href="#chunk-file-processing">Chunk File Processing</a></li>
                        </ul>
                    </li>
                    <li><a href="#proof-of-fee">Proof of Fee</a>
                        <ul>
                            <li><a href="#base-fee-variable">Base Fee Variable</a></li>
                            <li><a href="#per-operation-fee">Per-Operation Fee</a></li>
                            <li><a href="#value-locking">Value Locking</a></li>
                        </ul>
                    </li>
                    <li><a href="#resolution">Resolution</a>
                        <ul>
                            <li><a href="#operation-compilation">Operation Compilation</a></li>
                            <li><a href="#did-resolver-output">DID Resolver Output</a>
                                <ul>
                                    <li><a href="#unresolvable-dids">Unresolvable DIDs</a></li>
                                </ul>
                            </li>
                            <li><a href="#late-publishing">Late Publishing</a></li>
                        </ul>
                    </li>
                    <li><a href="#method-versioning">Method Versioning</a></li>
                    <li><a href="#context">Context</a>
                        <ul>
                            <li><a href="#recovery">recovery</a></li>
                            <li><a href="#operation">operation</a></li>
                            <li><a href="#usage">usage</a></li>
                            <li><a href="#publickeyjwk">publicKeyJwk</a></li>
                            <li><a href="#publickeyhex">publicKeyHex</a></li>
                        </ul>
                    </li>
                </ul>

            </div>
        </slide-panel>

    </slide-panels>

</body>
<script>window.specConfig = { "title": "DIF Sidetree Protocol", "logo": "https://rawcdn.githack.com/decentralized-identity/decentralized-identity.github.io/a3ca39717e440302d1fd99a796e7f00e1c42eb2d/images/logo-flat.svg", "logo_link": "https://identity.foundation", "source": { "host": "github", "account": "decentralized-identity", "repo": "sidetree" }, "output_path": "./www/spec", "spec_directory": "./docs/spec/", "markdown_paths": ["title.md", "abstract.md", "intro.md", "terminology.md", "versioning.md", "parameters.md", "common-functions.md", "topology.md", "file-structures.md", "did-uri.md", "json-web-signatures.md", "operations.md", "patches.md", "processing.md", "pof.md", "resolution.md", "method-versioning.md", "context.md"], "destination": "./www/spec/", "destinationResourcePrefix": "../../www/", "rootResourcePrefix": "./www/" }</script>
<script src="https://identity.foundation/sidetree/spec-up/js/markdown-it.js"></script>
<script src="https://identity.foundation/sidetree/spec-up/js/prism.js" data-manual></script>
<script src="https://identity.foundation/sidetree/spec-up/js/mermaid.js"></script>
<script src="https://identity.foundation/sidetree/spec-up/js/chart.js"></script>
<script src="https://identity.foundation/sidetree/spec-up/js/index.js"></script>

</html>